Boost logo

Boost-Build :

From: Christopher Currie (Christopher_at_[hidden])
Date: 2003-07-30 10:15:16

> In fact, I'm not sure about it. There are several scenarios involing
> dependency of one library on another:
> lib a : a.cpp b ;
> lib a : a.cpp : <library>b ;
> lib a : a.cpp : <dependency>b ;
> The first two cases are equvivalent, and should imply specific order of "a"
> and "b" on the command line.

This is not strictly true. Paraphrasing my previous example:

# Case 1
lib a : a.cpp ;
lib b : b.cpp a ;
lib c : c.cpp a ;
lib d : d.cpp b c ;
exe e : e.cpp d ;

explicit a ;
explicit b ;
explicit c ;
explicit d ;

# Case 2
lib a : a.cpp ;
lib b : b.cpp : <library>a ;
lib c : c.cpp : <library>a ;
lib d : d.cpp : <library>b <library>c ;
exe e : e.cpp : <library>d ;

explicit a ;
explicit b ;
explicit c ;
explicit d ;

These two cases do not behave equivalently. The second case seems fine
for shared librares, but when built with link=static, libraries 'a',
'b', and 'c' never get built, and therefore never get linked into the

The first case, however, behaves almost exactly as I would want this
syntax to do (although not as I expected). In the shared case, shared
libraries explicitly link in the libraries they depend on. In the static
case, the libraries are deferred until the executable is linked, and
they are placed in the correct order (with 'a' repeated, but this is
acceptable in the static case).

This difference in behavior was unexpected to me, because I took the
definition of 'sources' at its word, thinking that the system would try
and link static libraries to each other. Hats off to everyone for
putting in this intelligence in.

There remains a final problem with both cases, for shared libraries: the
linker knows that it needs to find '' and '', but because they
are built in 'bin/<toolset>/debug,' it can't find them. Not a huge
problem, it's just a warning, and the resulting executable runs fine, as
long as I update my LD_LIBRARY_PATH.

But it leads to my next question: how do I make all this work if I
*don't* want shared libraries to explicitly link in their dependencies?
(This is why I went with usage-requirements in the first place.)

> There's a question about the third one. The <dependency> feature is "weak"
> dependency --- it does not specify how 'b' is to be used by 'a' and in this
> case, it's not even used: only usage requirements are propageted.
> So, we can either introduce new feature <uses-symbol-from> which grabs usage
> requirements and also implies link line order, or make <dependency> imply
> link line order. The second solution is better, IMO, since for users,
> <uses-symbols-from> is a bit cryptic.

The second form would be better, better still if '<dependency>lib' also
implied 'usage-requirements += <library>lib'. Or, perhaps "case 2" above
could be altered to mean the combination of the two. Somehow I
instinctively feel that there ought to be some difference between having
a library in 'sources' and having it in 'requirements.'

> That's the story. As you can see, the issue is scheduled for Milestone 9,
> which is not very soon. But maybe, Ali can send still his patch? After all,
> it would make situation simply better that it is now. Ali, what do you think?

Despite my ramblings above, I do have workarounds for all of it, most of
which involve not using usage-requirements and explicity listing the
libraries as sources for the exe. There's no need to put in a patch if
it's not the proper solution.

Everything else aside, BBv2 is far superior to any other build tool I've
tried. I was almost giddy the first time I started seeing our project
build without twisted, unmaintainable Makefiles. Kudos to everyone involved.



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at