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:
> 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
> <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
> c) properties inherited from parent projects
> 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
> 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
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
>>> Here's my best guess about the semantics:
>>> a) It should be possible to say that one include directory comes before
>>> b) It should be possible to say that all the include directories in some
>>> come before all the directories in another group.
> 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:
> 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
> want the command line arguments to come after the values given in the
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk