Re: [BBv2] library dependencies and proper ordering

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

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 'b.so' and 'c.so', 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.

Thanks,
Christopher