[Tinyos Core WG] support/bin

[Jan Beutel]

On Tue, 2007-06-12 at 14:56 -0700, David Gay wrote:
> 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)?

i am totally fine as long this is one location for all these things that
one might want to put there. imho it can be a hierachy if necessary but
i rather prefer it flat...


> > 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

yes. i agree. i am ok with "any" way as long as it is consistent. and
today it is a mess (that i want to help clean up.) it's a mix of all
your three options above. step 5 of 
http://www.tinyos.net/tinyos-2.x/doc/html/install-tinyos.html
says to set env variables and that we all do. so there is no more need
to have ncc figure it out and report back.

moreover you can always override env variables if you have multiple
setups on one machine. but probably most people would be very happy with
just a toplevel config that is standard...

at least i would suggest to 

ifndef TOSDIR
TOS=$(shell ncc -print-tosdir)
elseif
TOS=$(TOSDIR)
SERIAL_H = $(TOS)/lib/serial/Serial.h

for the above to stay with a consistent behavior over the whole
system....


jan





-- 
Dr. Jan Beutel                              j.beutel at ieee.org
Computer Engineering and Networks Laboratory, ETZ G75
ETH Zurich                             +41 44 632 70 32 Phone
Gloriastrasse 35                         +41 44 632 10 35 Fax
CH 8092 Zurich/Switzerland  http://www.tik.ee.ethz.ch/~beutel