[Tinyos Core WG] support/bin

[Jan Beutel]

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.

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

jan


> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
-- 
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