Re: [Boost-build] Sorting include headers

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

On Wed, Oct 15, 2008 at 11:44 AM, Phillip Seaver <phil_at_[hidden]> wrote:
> Alexander Sack wrote:
>> As per FAQ:
>>
>> http://www.boost.org/doc/tools/build/doc/html/bbv2/faq/s04.html
>>
>> The boost build system seems to sort header files.  Is there any way
>> to turn that off completely?  I know a long shot but to be honest,
>> this is a very very (VERY) annoying feature of bjam.  It should
>> preserve the order in which is specified on the command line (I don't
>> see why internally it needs to do this).
>>
>
> >From http://lists.boost.org/boost-build/2004/08/7084.php
>
>> Some more information. The properties are sorted for performance
>> reasons. We do quite a lot of work with property sets and try to cache
>> results. For caching to really help, differences in order should be
>> erased:
>> "<variant>release <debug-symbols>on" and "<debug-symbols>on
>> <variant>release" are exactly the same.
>
> As I understand it, the property sets are just strings (or lists of
> strings), so if they're not sorted, they would have to either sort
> before comparing or check each item in one set against the items in the
> other set.  Property sets are usually *much* longer than the simple
> example above, so it can make a very substantial difference, especially
> for large project trees.

Maybe so but is the performance that BAD to induce build errors and
other link nastiness?

>> In a prior thread, it was recommended I can use alias but again, how
>> do ensure the order of includes is preserved (and for my production
>> PROJECT it does matter - I'm not going to rewrite source just yet to
>> avoid obvious namespace collisions, the current build just puts the
>> includes in the right order and things compile).
>
> The same kind of problem has hit us a few times.  I usually try to fix
> the code, because it just seems like a never-ending problem otherwise.
> It can be a pain, but so are "random" compile problems when the order of
> headers changes or a new library comes in with the same name.

Yeah totally agree with you Philip but in order to evangelize a build
tool I have to at least proof that bjam can build the exact pieces of
code that autoconf and friends can (a true source of industry
evilness).

> Unfortunately, I don't have an easy solution for the ordering problem.
> You could probably do something like take all the relative paths,
> convert them to full paths (in bjam), and join them with "&&".  I don't
> know off the top of my head how to write that, though.

What's this means though is in order to preserve the order I either have to:

- Move the headers in an order that works (i.e. move files around)
- Alphabetize my directories so it magically gets sorted in a buildable way
- Specify dozens of headers on the target rule using the && syntax (ugly as sin)

Uhhh this is gonna be a tough sell!  :D

-aps