From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-05 13:11:28
David Abrahams wrote:
>>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
>>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.
I worry about it too. This runtime link issue is *very* complicated.
>>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.
If there are 10 libraries, it would have fewer characters than (2).
>>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.
The problem is that computing values of features from values of some
other features is completely new concept. I'd rather avoid it
if we can.
>>That would be rather tricky,
> Do you mean "tricky to implement in Boost.Build"?
That, and that's such semantic is tricky for user to understand.
>>and I don't know what it gives us.
> I don't know what you mean.
I don't see any advantages over <shared> only scheme. Is there
anything you can't do with <shared>?
>>>>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".
1. You can specify static linkage for each dependency explicitly.
2. We probably can introduce new section which overrides properties
propagated to all dependencies.
lib a : a.cpp lib1 lib2 lib3 lib4 lib5 : <shared>true
: propagated <shared>false
This is just a syntactic sugar when compared with specifying
<shared>false for each dependency. (I know you say that
syntax sugar matter, I'm just saying it's relatively
>>>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.
Aren't the approaches I describe above sufficient? By default,
"somebody" determines linkage. Each library can override that
decision, if it likes.
>>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.
OK, let me know what you think of what I say above.
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