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

[Philip Levis]

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