Re: [Boost-build] Sorting include headers

Subject: Re: [Boost-build] Sorting include headers
From: Alexander Sack (pisymbol_at_[hidden])
Date: 2008-10-25 09:48:21

On Thu, Oct 16, 2008 at 3:46 PM, Alexander Sack <pisymbol_at_[hidden]> wrote:
> On Thu, Oct 16, 2008 at 12:34 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>> 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.
>
> Yes this is what I was talking regarding a feature to control this a bit.
>
>> 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.
>
> Sure Steven.  I've requested a Trac account so I can enter it.
>
> -aps
>

https://svn.boost.org/trac/boost/ticket/2433

-aps