[Tinyos-devel] Re: [Tinyos-help] .platform question

[Kevin Klues]

OK, I think you've convinced me that %C might be a bad idea with the
argument that the tinyos-2.x-contrib isn't the only place for outside
contributions to come from.  Tying %C to just this single outside source
would be a hack and probably not the right thing to do.

Let's standardize on the environment variable used for contrib though so
that .platform files, etc can be set up once and others can use them as long
as they have the proper environment set up.  Martin uses, CONTRIBROOT, I
proposed TOSCONTRIBROOT, and David proposes TOSCONTRIB.  Since we decided
its best not to use %C, I am leaning more towards davids proposal now, so
lets' go with TOSCONTRIB.

To make this work we need to then:

Add this environment variable to the .profile file (or wherever environment
variables are set up):
export TOSCONTRIB=/path/to/tinyos-2.x-contrib

in the .platform file do

$ecosensdir = "$ENV{TOSCONTRIB}/ecosenys"
push( @includes, qw(

  $ecosensdir/platforms/ecosens1
  $ecosensdir/platforms/ecosens1/chips/stm25p
  $ecosensdir/platforms/ecosens1/chips/cc2420
  %T/chips/cc2420
  %T/chips/cc2420/alarm
  %T/chips/cc2420/control
  %T/chips/cc2420/csma
  %T/chips/cc2420/interfaces
  ...
  ...

Kevin

On Dec 17, 2007 10:33 AM, Philip Levis <pal at cs.stanford.edu> wrote:

> On Dec 17, 2007, at 10:13 AM, Martin Leopold wrote:
>
> >
> > Hi Phil.
> >
> > I think you are taking this in a spirit then it was meant - while
> > it may
> > or may not make sense to have a %C built into ncc, I can't see the
> > harm
> > in defining a named env variable for the location of contrib. Contrib
> > has other provisions that projects must follow, this would just be one
> > more.
> >
> > Most project will probably end up defining their own variable with the
> > same purpose - the way I see it Keven merely proposes that all
> > projects
> > agree on the name.
> >
> > On Mon, 2007-12-17 at 08:34 -0800, Philip Levis wrote:
> >> I do. Why should contrib -- a social construction that happens to be
> >> the way it is mostly due to sourceforge licensing and CVS checkout
> >> structure -- determine parameters to the compiler? If contrib were in
> >> tinyos-2.x (as it is in 1.x), then this would not be necessary. It's
> >> not very hard in a Makefile to
> >>
> >> RCHIPS=/opt/tinyos-2.x/contrib/rincon/tos/chips
> >>
> >> CFLAGS +=$(RCHIPS)/cc2420 $(RCHIPS)/at45db
> >
> > And what if I install contrib in say /home/leopold/tinyos-2.x-contrib?
> >
> > Having a common variable would enable a common make-rule that requires
> > no modifications:
> >
> > RCHIPS=$(TOSCONTRIBROOT)/rincon/tos/chips
> >
> >> It might make more sense to define a variable in Makerules that
> >> derives contrib from TOSDIR/TOSROOT. Application makefiles can
> >> override it, etc.
> >
> > Is there a mechanical relation between the two? I mean is there a
> > way to
> > derive the location of contrib from the location of TOSROOT? For
> > example
> > I have more than one "contrib" directory - one is the sourceforge and
> > one is my local svn tree, how would I pick one or the other?
>
> You can do the variable today, with no changes to ncc. So it's not a
> big thing to discuss.
>
> My concern is binding the idea of "contrib" into ncc as %C. Doing so
> seems like a simple hack. Minimizing the number of hacks in the core
> is a good thing. For example, while this might solve the contrib
> problem, it doesn't solve the problem of someone who wants to
> distribute code outside contrib.
>
> I'd be all for a mechanism that can solve the general case, but am
> leery of adding a special case like this.
>
> Phil
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>



-- 
~Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20071217/1388b382/attachment.html