Re: [Boost-build] Sorting include headers

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

AMDG

Alexander Sack wrote:
>> All right. how should include ordering work?
>>     
>
> At the bare minimum bjam should honor the order the rules were written
> in or at least provide a simple build feature that allows for this.
> Other than some performance gains in set comparisons, I don't see why
> you wouldn't have this.
>   

It's not just about faster comparisons.  Consider

<include>abc <include>xyz

vs.

<include>xyz <include>abc

Should these be considered equivalent or not?

Also, what do you mean by honoring the order in which rules are written.
properties can come from:

a) The target definition
b) The project containing the target
c) properties inherited from parent projects
d) usage-requirements of dependencies
e) command line arguments

what order should these go in?

>> I don't think that it is a good idea to rely on
>> the order implicitly as include directories can be
>> specified in many different places.  If it actually matters,
>> the dependencies should be explicit.
>>     
>
> Though I agree in principle that code should be written better and
> namespace pollution should be avoided, the fact is if you want folks
> to adopt bjam it has to deal with projects already in place.

I meant that if the order matters the Jamfile should specify this 
explicitly.

>> Here's my best guess about the semantics:
>>
>> a) It should be possible to say that one include directory comes before
>> another.
>> b) It should be possible to say that all the include directories in some
>> group
>> come before all the directories in another group.
>>     
>
> Absolutely.
>   

We don't want this to expand into a quadratic number of features, so
<include>a&&b&&c indicates that a should come before b,
and b should come before c, currently.

We would need to get something like this:

<include-order>a&&b->c&&d

A rule like the following could generate it

rule set-include-order ( before * : after * )
{
    return <include>$(before:J=&&)->$(after:J=&&) ;
}

This should probably be generalized for other free features.

>> c) If a directory is specified more than once it should only be put in
>> the command line once and should obey the union of all constraints on it.
>> d) These constraints need to encoded in the property-set somehow--they
>> can't be global, as different targets may need different constraints.
>> e) It should at least be possible to make directories specified on
>> the command line come before directories that come from the jamfiles.
>>     
>
> What's the purpose of the last one with respect to this context?
>   

I'm just trying to consider all the places that <include>s can come from.

This needs to be handled more generally.  For instance, for cxxflags, we 
probably
want the command line arguments to come after the values given in the 
Jamfile.

In Christ,
Steven Watanabe