Re: [jamboost] Re: [Boost.Build V2] Couple of newbie questions.

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-04 01:41:52

"klapshin wrote:

> > 1. Restrict the library to being dynamic. For example
> >
> > lib a : a.cpp other_lib : <link>shared ;
> >
> > or
> >
> > shared_lib a : a.cpp other_lib ;
>
> Effectively giving up ability to link library as static or dynamic
> for any library having dependencies? This will make the whole idea
> of being able to easily link library one way or another pretty much
> unusable.

Yep, I don't like this alternative as well.

> > 2. Don't use libraries in sources. I've explained that previously,
>
> and will
>
> > commit an update to documentation soon. In short:
> >
> > lib a : a.cpp : : : <library>other_lib ;
> >
> > Now everybody who links to "a" will pick "other_lib" as well.
>
> Wait a second. So since we put other_lib into requirements,
> everybody linking to lib "a" will link to "other_lib", even if "a"
> is dynamic? That does not sound right. That would be a correct
> behavior for static but not dynamic libs.
> My understanding is that if "a" is linked as dynamic library it
> should get linked against "other_lib", but everybody who uses "a"
> should only get linked against "a", not "other_lib". For "a" being
> linked as static lib on the other hand, everybody linking to "a"
> should also get linked to "other_lib" automatically.

This is reasonable. OTOH, when both "other_lib" and "a" are dynamic, then if
you link "other_lib" into "a", "a" will only contain a reference to 
"other_lib", IIRC. Essentially, when applications links to "a", the linker 
will notice the reference to "other_lib" and resolve more symbols. At 
runtime, the linker will notices the reference and load 'other_lib' when 'a' 
is loaded. This is almost the same as linking all the needed to the 
application. 

The only difference is when the generated library should be used outside 
Boost.Build.

> So looks to me that conceptually other_lib is source for dynamic
> lib "a" and a requirement for static lib "a".
> Don't know how to get around this problem. My preference would be
> adding libraries to sources, and then for static libs, removing them
> from sources and moving to requirements. Since I know nothing about
> boost.build internals I have no idea if it is feasible at all.

So, the idea you're proposing is this:

1. It reasonable desire to combine libraries in other libraries
2. When dynamic library is created, it's OK.
3. When static library is created, this does not work. For that
reason, when creating static library we should convert library sources
into usage requirements.

Uhm. the automatic moving of sources into usage requirement should be
possible without too much effort. But is it really better? For linking targets
inside Boost.Build it makes no different. If you want to use the generated
library outside Boost.Build, you either have to make it dynamic, or tell
the users to link all other libraries it depends upon. (Or course, in current
design, you'd have to link all the other libraries even if library is 
dynamic).

- Volodya