Re: [Boost-build] Sorting include headers

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

On Thu, Oct 16, 2008 at 11:06 AM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> 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.

Parlance exception - features can have project scope, that's all I meant.

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

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

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.

> The target specific requirements override everything else.

Yes.

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

I'd have to think about that but you definitely bring up a good point.
 How should usage-requirements be treated since they are really
hidden...my guess is if the user really specifies usage-requirements
than I would expect those to be inserted AT THE POINT where the
dependencies are inserted and in the order in which the
usage-requirement was specified...

-aps