Re: [Boost-build] Sorting include headers

Subject: Re: [Boost-build] Sorting include headers
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-10-16 11:06:07

AMDG

Alexander Sack wrote:
> 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.?
>   

Features are never per-project.  They can be set for a project,
but it is always possible to override the project settings for a specific
target.  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.

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

All right.  Let's see if I understand correctly.  Given the following:

Jamroot.jam:

project myproject : requirements <include>a ;

foo/Jamfile.jam:

project myproject/foo : requirements <include>b
alias c : : : <include>c ;
exe foo : foo.cpp c : <include>d ;

bjam foo//foo include=e

the command line to be

-Id -Ic -Ib -Ia -Ie

The target specific requirements override everything else.
Every project's settings override the parent project's settings
(this is the same as for ordinary features, so far).  I'm not quite
certain where the usage requirements belong.  I could argue that
since they are at the level of individual targets, they should
override the project settings or I could argue that they are
more hidden, and thus should take lower precedence.
A similar argument goes for the command line.  The command
line is global, but is explicitly set by whoever runs bjam.

In Christ,
Steven Watanabe