Re: bjamv2: includes lexicographically sorted

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-08-24 01:25:56

Toon Knapen wrote:

> I have in my top-Jamfile following :
> 
> project
> : requirements
> <include>/home/tk/cvstop/myproject
> <include>/home/tk/cvstop/boost
> <include>/home/tk/cvstop/boost-sandbox
> ;
> 
> On the compile-line, the includes are however lexicographicall sorted
> like this : -I/home/tk/cvstop/boost -I/home/tk/cvstop/boost-sandbox
> -I/home/tk/cvstop/myproject

That's a issue BB35:

http://zigzag.cs.msu.su:7814/scarab/issues/id/BB35

(something like year old)

> However, the order of the include-directories is important to me. Is
> there a way to surpress this lexicographical sort ?

Yes, though you'd need to do "cvs up" first ;-) I've just comitted revision
1.25 of build/toolset.jam which allows to write:

: requirements <include>/home/tk/cvstop/myproject&&<include>foobar 

This syntax specifies to include paths, and they will be passed to the
linker in the specified order. Points to note:

1. This is experimental feature. I've made up the syntax some time ago,
but I'm not promising it's 100% optimal.
2. Use it only for cases where the order *really* matters.

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.

But some features, in some cases, should be in fixed order. The <include> is
one example. The <find-shared-library> (which translates to -l options on
Unix) is another. Preventing sorting for <include> had bad performance
impact. So I've decided to invent new syntax to indicate where order should
be preserved. This syntax is already used internally for
<find-shared-library>, and my last commit only made it work for <include>
also (actually for all 'path' features).

Please let me know if it works for you.

- Volodya