From: Christopher Currie (Christopher_at_[hidden])
Date: 2004-01-29 17:06:12
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
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.
This problem also effects library ordering, which I know is not
implemented yet, 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.
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