[Tinyos Core WG] support/bin

[David Gay]

On 6/12/07, Jan Beutel <j.beutel at ieee.org> wrote:
> On Fri, 2007-05-18 at 17:58 -0700, David Gay wrote:
> > On 5/18/07, Philip Levis <pal at cs.stanford.edu> wrote:
> > > On May 18, 2007, at 3:55 PM, David Gay wrote:
> > >
> > > > On 5/18/07, Philip Levis <pal at cs.stanford.edu> wrote:
> > > >> Net2 met today, and the folks from JHU are ready to check in Deluge
> > > >> for 2.0. There's one blocking item, which is the decision of whether
> > > >> to put  the command-line tools in tools/ or support/. Since they are
> > > >> command line tools, they benefit from being separate from support/
> > > >> sdk/
> > > >> python/blah/blah. The conclusion was that we need a support/bin,
> > > >> which has end-user scripts. tos-mviz would probably migrate there.
> > > >>
> > > >> Are there any objections to creating a support/bin?
> > > >
> > > > Didn't get round to answering in the "private" thread. My issue here
> > > > is that having a support/bin, installed somehow when you install the
> > > > rpm, gets in the way of either:
> > > > - a relocatable rpm as we have now
> > > > - or, actually being an rpm-kind of thing which tracks groups of
> > > > installed files (to make it relocatable and have tools in support/bin,
> > > > you end up needing to do some magic in post-install scripts to put the
> > > > files somewhere, or to mess with the user's path which is even worse)
> > > >
> > > > What's the real problem in having them in tools? Version dependency
> > > > issues can be addressed by placing appropriate requirements on
> > > > tinyos-tools in the tinyos rpm.
> > > >
> > > > I really do think life is easier with a "real rpm" (tinyos-tools) and
> > > > a "convenient tarball-like thing" (tinyos)
> > >
> > > Well, except that the tarball-like thing has stuff like support code,
> > > like tinyos.jar...
> >
> > However that stuff lives in the tos hierarchy when in use (unlike
> > command-line tools).
> >
> > > My motivation for support/bin was to be able to separate tools RPM
> > > distributions from tinyos RPM distributions. The idea that a change
> > > to Deluge that requires a change to its scripts requires a tools RPM
> > > update seems like a pain; better to keep changes localized. Now that
> > > we're moving to more frequent 2.0 releases, I'd like to avoid having
> > > to release tools nearly as often and go through the testing cycle for
> > > them.
> > >
> > > I'm willing to stick with tools/ for now just because it doesn't
> > > change anything;we can later figure out if these are issues in
> > > practice or tools/ is fine.
> >
> > My motivation here is that we used to do a single combined tools+tos
> > rpm for 1.x, and it was a pain. Having 2 rpms seems a lesser pain so
> > far. If we're going to go back to having some tools in the tos rpm,
> > we'll end up with the worst of both (two rpms + the support headache).
> >
> > David
>
> apart from the issue of packaging it into rpms i must say that it would
> be very helpful to have a distinct location within $(TOSROOT) where
> appropriate tools are located. not everyone has the right/wants to be
> root on their machine and some of us carry along a number of versions of
> tools and tos (and other projects) on one setup... so would vote to have
> a /bin ASAP no matter where it is as long as all the stuff generated
> within $(TOSROOT) that is executable get's put (make install) there.

What's wrong with ./configure --prefix=<where I want to put the
tools>? (e.g., --prefix=$HOME)?

> btw. in the light of defining $(TOSROOT) and $(TOSDIR) is it still
> necessary to have makefiles use ncc to "find" these variables or can we
> just clean this out?
>
> TOS=$(shell ncc -print-tosdir)
> SERIAL_H = $(TOS)/lib/serial/Serial.h
>
> i find it to be a real nuisance...

Frankly, the alternatives in this space are (this applies to the tools too):
1) hardwire paths (but make them easy to change at build time)
2) use environment variables/registries/etc (things break if they aren't set)
3) both (i.e., there's a hardwired default overridden by an
environment variable)

I will point out that the Unix world has played around in this space
for 30 years or so, and Linux and most open source projects have
settled on number 1. So I'd want to hear a really good argument for
doing 2 (we currently do a mix of 1 (tools) and 3 (TinyOS tree)).

David