Re: [Boost-build] Sorting include headers

Subject: Re: [Boost-build] Sorting include headers
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-10-16 12:34:08

AMDG

Alexander Sack wrote:
>> I think that this should still work.  For instance if we have a
>> bunch
>> of includes from inherited from multiple parent projects, and these
>> parent projects do not care about include order, if include order does
>> matter for a specific target, we can put the parent project requirements
>> in some random order and then treat it as if the order matters afterwards.
>>     
>
> Correct.
>   

Alright.  one more generalization:

<free-feature-order:include> which can be either none, forward, or reverse

none means that we don't care about order
forward means that value "a" can override value "b", "a" should come
  after "b".  (This is how cxxflags would work, I think).
reverse is similar except that earlier values override later ones.

Actually, (IMO) it would be better to make this a global property of the 
feature.
There is already an "order-sensitive" attribute which is currently ignored.

feature "include" : : free path order-sensitive-reverse ;

It's possible that the property-set data structure can be tweaked
so that the performance cost is small.  It would have to be
changed to something more complex than a sorted list of strings.

>> -Id -Ic -Ib -Ia -Ie
>>     
>
> YES!!!!!  :D!  Call me crazy but this makes A LOT more sense than what
> is happening today.  From a user stand point it states the following:
>
> I want to build foo, foo needs to include d oh and any of the
> dependencies from c and then any project hierarchical requirements
> that maybe specified.
>
> BTW, it also has the nice side effect of being able to debug how bjam
> formulated the overall compiler invocation by just looking at it.
>   

Ok.  This is going to be a significant amount of effort.  Can you
file a trac ticket at http://zigzag.lvk.cs.msu.su/boost.build so it
doesn't get lost.

In Christ,
Steven Watanabe