Re: [Boost-build] Sorting include headers

Subject: Re: [Boost-build] Sorting include headers
From: Alexander Sack (pisymbol_at_[hidden])
Date: 2008-10-16 10:15:24

On Wed, Oct 15, 2008 at 3:58 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> 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?

As I understand compilation, they are different unfortunately.  Order
of includes matter.  If you treat these paths as equal than you need
the syntactic messiness of specifying order where I believe it should
be completely reversed, i.e. if you want bjam to treat the above as
equal, than add some feature as a build performance gain since AFAIK
that is why bjam is doing it.  What about a feature on a per project
level that allows for <include-sorting>off etc.?

> Also, what do you mean by honoring the order in which rules are written.
> properties can come from:
>
> a) The target definition

I wrote these didn't I?

> b) The project containing the target

Same.

> c) properties inherited from parent projects

Same.

> d) usage-requirements of dependencies

This can get tricky.  But I would say the order in which the
dependencies are resolved are the order in which the headers are
passed to the compiler (and in the sub order grouping of each
usage-requirement).

> e) command line arguments

These should come last.
>
> 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.

Again, I totally agree that code should be explicit and namespace
pollution should be avoided.  However, I also believe there are
instances where include order makes a difference and there has to be a
better way to do this.

>> 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.

Alright, as I stated before, then it has to be an easy way to do this.
 The current syntax doesn't deal with groups of headers which
stinks!!! :)

>>> 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.

Agreed.

-aps