From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-01-30 06:40:33
> I've been struggling recently with what seems to be a recent change to
> BBv2, in that property-lists are now kept in collation order. This
> causes problem when you need to guarentee that one property has effect
> before another.
That was the behaviour for quite a long time. In fact, the only version where
it was not true was so slow that you would not even think about using it ;-)
Another thing about this is really really funny... when I say your email I had
another mailer window open with half-composed email entitled
> An example: a machine comes with a system curses library that is old and
> broken, so I want to use a replacement libcurses, which I have installed
> in /usr/local/lib. but I also need to link against another library (say,
> pthread) in /usr/lib, which also has my system's broken curses.
> So my project would look something like:
> project my/project ;
> CPP_SOURCES = foo.cpp bar.cpp ;
> lib libcurses : : <name>curses <search>/usr/local/lib ;
> lib libpthread : : <name>pthread <search>/usr/lib ;
> exe app : $(CPP_SOURCES) libcurses libpthread ;
> When I run bjam against this, my <search> properties get sorted, such
> that /usr/lib is put before /usr/local/lib. So my command line now ends up:
> g++ -g -L"/usr/lib" -L"/usr/local/lib" ...
> So my build picks up the wrong library. From what I can tell, there's no
> way to circumvent this, even by putting an explicit <library-path>
> property on the exe, because the sorted property list picks up the
> duplicate and throws it away.
That's true. It also affects <include> properties, as
tells me (and that hit another user)
> This problem also effects library ordering, which I know is not
> implemented yet,
Not comitted yet ;-) I have a draft implementation which is stalled on this
> but I could work around it before by making sure my
> libraries were listed in the proper order in the exe rule. Now, if
> libpthread (for example) were to depend on libcurses (obviously they
> don't but bear with me), I'd have no way of making that happen, because
> they'll be sorted on the command line.
> Any thoughts? I personally can't see any way around it other than not
> sorting property lists, but perhaps I'm missing something.
There are two alternatives. First is not sorting them anything all. This might
cause too many property-sets which are equvivalent but have different
property order. That can slow things down.
Second alternative is not sorting some of the properties -- 'order-sensitive'
ones: <include> <library-path>, <find-shared-library> and so on.
I'm going to find out if first approach will really lead to considerable
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk