Re: [jamboost] Re: [BBv2] library dependencies and proper ordering

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-08-05 03:32:57

Hi Christopher,

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

:-( Not nice.

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

Oh.. I think you hat can stay on your head yet --- you've just discovered an 
interesting behaviour that I was not aware of. V2 always passed unused 
sources unmodified though the generation process. So here, when generating 
"b" with link=static you get two target: for 'b' and for 'a'. Had no idea 
this can be turned to advantage.

I believe we have to think a bit more about how libraries work and improve 
things. 

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

<ot>
FYI, there's <hardcode-dll-paths> true property which will cause executable to 
run without LD_LIBRARY_PATH. The downside is that shared libraries can be 
longer moved to a different location, so this is usefull mainly for 
debugging.
</ot>

What is needed to suppress the warning? -L switches which point to the 
locations of all linked libraries?

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

Well... I think you put libraries in usage-requirements... and maybe add some 
<dependency> on libraries to get usage requirements.

Exes will link to all required libraries. I'm actually not sure why I don't 
get warning from linker.... even in release builds where I don't use 
<hardcode-dll-path>. And I'm actually put all libraries in usage requirement 
in my project.

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

In fact your first example makes me wonder if <library> is necessary at all.
Really, some consideration is necessary and hope will start and finish it in 
some reasonable time.

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

Thank you! In fact, that similiar to how I switched to Boost.Build myself 
(version 1 back then). Before that, I've used, for example, borland-specific 
makefile flags for dependency scanning and had no idea how to do the same 
with GNU make. Not to mention different suffixes, different command line and 
the list goes on...

- Volodya