Re: [jamboost] [BBv2] sorted property lists

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-01-30 06:40:33

Hi Christopher,
> 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 

"Order-sensitive properties"

> 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

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

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 
very problem. 

> 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 
slowdown.

- Volodya