Re: [Boost-build] Dependency on shared library from static library(mixing shared and static libs)

Subject: Re: [Boost-build] Dependency on shared library from static library(mixing shared and static libs)
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2009-02-06 07:24:40

Vladimir Prus wrote:
> On Tuesday 03 February 2009 16:21:53 Johan Nilsson wrote:
>
>> consider the following:
>>
>> - Library "a" that can be built for shared or static linking.
>> - Library "b" depends on "a", but can only be built for static
>> linking.
>> - App "c" depends (directly) on "b".
>>
>> All the above are defined as Boost.Build targets within a single
>> project.
>>
>> I would like to be able to:
>>
>> 1. Build app "c" to use the shared version of "a" (e.g. bjam
>> link=shared):
>>     - Link statically to "b" (as this is the only possibility)
>>     - Link shared to "a"
>>     - Lib "b" should reference the shared build of "a"
>>
>> 2. Build app "c" to use the static version of "a" (e.g. bjam
>> link=static):
>>     - Link statically to "b"
>>     - Link statically to "a"
>>     - Lib "b" should reference the static build of "a"
>>
>> Please see attached zipfile or the extracts below for a non-working
>> example - if I run "bjam link=shared" the app "c" is statically
>> linked to both "a" and "b" - presumably because the <link>static for
>> lib "b" is propagated to lib "a" as well.
>>
>> Any ideas on how to work around this problem? I've tried fiddling
>> around with the requirements for the different targets to no avail.
>
> This is not possible. As soon as 'b' gets <link>static via
> requirements,
> it will propagate that property to all dependencies, and there's no
> way to
> stop that. Maybe, we need a special syntax to indicate either:
>
> - <link>static is for this target only, don't propagate it further,
> e.g:
>
> lib b : b.cpp : *<link>static ;

Do we really need a special syntax. What about e.g.:

- lib b : b.cpp : <link>static -<propagate>link ;
- lib b : b.cpp : <link>static <link-propagate>no ;

OTOH; the usage of "propagate" could indicate that the "outer" (requested) 
link should also not be propagated. Then, what about e.g.:

- lib b : b.cpp : <link>static <passthrough>link ;
- lib b : b.cpp : <link>static <link-passthrough>yes ;

>
> - When building a dependency, we need not use target's requirements,
> e.g.:
>
> lib b : b.cpp a/<link>* : <link>static ;

With reference to the above:

- lib b : b.cpp a/-<propagate>link : <link>static ;
- lib b : b.cpp a/<link-propagate>no : <link>static ;
(or)
- lib b : b.cpp a/<passthrough>link : <link>static ;
- lib b : b.cpp a/<link-passthrough>yes : <link>static ;

But - all of these latter ones looks like we are requesting a build where we 
are setting a property of "a" instead of "b". Compare to e.g. 
"a/<link>shared".

What about this instead:

- lib b : b.cpp a : <link>static <link-passthrough>a ;

or (for passing link through to all relevant dependencies):

- lib b : b.cpp a b c x : <link>static <link-passthrough>* ;

>
> will cause 'a' to be built with whatever properties 'b' was requested

I assume that you mean "... with whatever link property ..." ?

> (say,
> on command line) -- ignoring <link>static.
>
> I'm not sure which approach is best -- do you have an opinion?

Don't the two examples express the same thing, but the latter additionally 
allows "passing through" the requested link type for only certain 
dependencies? The latter is more generic, but I'm not sure how useful it 
would be in practice.

One sidenote though: what's the rationale for adding libraries to the 
"sources" part of the target as in your examples above (which seems to be 
pretty common)?

/ Johan