From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-05 11:49:28
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
2. Explicitly specify <static> when referring to those libraries:
lib a : a.cpp cool_lib/<shared>false : <shared>true ;
3. Introduce another feature:
lib a : a.cpp cool_lib : <shared>true <shared-dependencies>false ;
The third approach saves typing. 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>... That would be rather tricky,
and I don't know what it gives us.
>>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.
>>So, <shared> is propagated. If you introduce another feature, then I
>>cannot say <shared>true on a single exe and have all dependency libs
>>built as shared too.
> 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? 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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk