Re: runtime-link

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
> specifications.

Right.

>>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
lightweight concept).

> 
> 
>>>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.

- Volodya