[Tinyos Core WG] support/bin

[David Gay]

On 6/13/07, Jan Beutel <j.beutel at ieee.org> wrote:
> On Tue, 2007-06-12 at 14:56 -0700, David Gay wrote:
> >
> > 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...

I'm not sure what you mean, if you could elaborate...

FWIW, the --prefix used by configure points to the base of a
unix-style /usr directory hierarchy (with bin, lib, man, etc
subdirectories).

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

Well there's a bunch of separate issues here:
- two of the environment variables are paths so that other tools (java
(CLASSPATH) and the shell (PATH)) can find the TinyOS stuff
- TOSDIR vs TOSROOT. I'd be happier with one less of these - I put in
TOSDIR to point ot a TinyOS source tree, and Kristin added TOSROOT to
get to the "other" stuff. We should probably drop one of the two.
   Doing a grep for TOSROOT in tinyos-2.x suggests that it's not
really currently used:
   - one use should be using the tos directory from ncc -print-tosdir
   - one use is in tos-check-env, could be changed
   - one use is internal to the tinyos spec file
   - it's mentioned in the install/upgrade installation, and the
Oscilloscope READMEs
- MAKERULES is the only real case of #2 (something whose location is
only specified by an env variable)

More generally, I think it's worth distinguishing executables (the
contents of tinyos-tools) from source code (the tinyos package).

For executables (which we often obtain from elsewhere), I'll argue
again that it's not worth the effort to make them movable at install
time - use the existing tools of building for different prefixes and
setting your PATH if you're one of the few people who need to deal
with multiple incompatible toolsets.

For source code, we already support moving via TOSDIR - the only
argument is whether there should be a default value for TOSDIR built
into ncc (the cost is having to do ncc -print-tosdir to get the value
of TOSDIR).

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

I'm confused by this suggestion. ncc follows 3, where the TOSDIR env
variable overrides the builtin path, so it already does the equivalent
of the ifndef/elseif above.

David