Re: [jamboost] Re: runtime-link

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 12:13:06

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> I don't think we're saying the same thing.
>> 
>> It is possible to build a shared library which links statically to its
>> dependencies, is it not? This is an important usage model, at least on
>> Windows, where shared library vendors want to reduce the chance that
>> the installation of some newer (or older) shared "system" library
>> version will break their product in the field.
>
> I can see three solutions:
>
> 1. Specify <static>false in requirements for those libraries

That's intrusive. You may not have control over their target
specifications.

> 2. Explicitly specify <static> when referring to those libraries:
>
> lib a : a.cpp cool_lib/<shared>false : <shared>true ;

OK, I like it. Though I worry about how this applies to the runtime
library, which is usually not explicitly named.

> 3. Introduce another feature:
>
> lib a : a.cpp cool_lib : <shared>true <shared-dependencies>false ;
>
> The third approach saves typing. 

How? It seems to have the most characters.

> But you get another problem: If <shared-dependencies> affect how you
> link dependencies and <shared> affects how targets are built, you
> need to make those features consistent.
>
> Imagine that there's another lib that "a" uses: cool_lib2, which is
> build from sources. If you want to link it statically, you have to
> build it statically, for the value of <shared> for it my be computed
> from the value of <shared-dependencies>... 

<shared-dependencies> is set to false above, so I don't see a problem.

> That would be rather tricky,

Do you mean "tricky to implement in Boost.Build"?

> and I don't know what it gives us.

I don't know what you mean.

>>>I view the current "shared" as saying: "use shared linking whenever possible".
>>>Of course, if you want to use shared linking for exe, you'd have to use
>>>shared linking for dependencies that are libraries. 
>> 
>> 
>> What about dependencies of those libraries?
>
> By default, <shared> is propagated to those libraries too. But they can
> make a choice for themself.

That makes it hard to say "I'm a shared library which links statically
to my dependencies".

>> I think it's important to be able to specify shared linking with one
>> broad stroke, but I'm not sure it should be propagated more than one
>> level through the (abstract) dependency graph.
>
> What problems do you see in propagating them all the way? 

Just that shared library implementors often need to be able to decide
for themselves how they will be linked to their dependencies. It
shouldn't be determined by someone higher up the chain.

> Because I see a couple of problems with doing otherwise:
>
> 1. We don't have any "broad stroke" approach. Even properties
> in build request (from command line) apply only to
> directly requested target, as we've discussed and agreed before.
>
> 2. Say I have two executable. One must link everything statically,
> and another dynamically. With your approach, I can affect only
> their direct dependencies.

I agree. I'm not really wedded to an approach. I'm just trying to
outline the problems right now.

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution