Re: [jamboost] Rename of <include> causes include search path to change

From: Craig Rodrigues (rodrigc_at_[hidden])
Date: 2005-08-03 10:05:59

On Fri, Jul 29, 2005 at 04:08:40PM +0400, Vladimir Prus wrote:
> Internally, Boost.Build sorts all properties, to speed up something.

What speeds up by sorting the properties? Is there some kind of lookup
mechanism?

> If you need a specific order of a specific includes pair, the current syntax 
> is
> 
> <include>some_dir&&another_dir
> 
> This is relatively new and untested part of the code, so feedback is very 
> welcome.

Well, I'm not a big fan of this syntax.....it is non-intuitive.
For people migrating from Makefiles, Visual Studio project files, etc.,
it is quite surprising that the order that you specify <include>
directories is not the order passed to the toolchain.
For most cases, this is probably not a problem, but for huge
oddball projects like mine, this can be a problem.

Would it be possible to sort all properties, but
maybe group <include> and <library-path> and leave them in the
same order they were specified in a Jamfile?

-- 
Craig Rodrigues 
rodrigc_at_[hidden]