Re: runtime-link

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-05 12:10:07

David Abrahams wrote:

>>>In that case it seems very strange to use this as a feature in a
>>>target's requirements section to indicate whether it is a shared or
>>>static library.
>>
>>Why? Specifically, it is strange to use it in *requirements* section.
>>Or it it strange to use a feature. Or what.
> 
> 
> It is strange to use it in the requirements section when it sometimes
> expresses a preference for dependencies.

Not sure you'll buy this, but recall the "stage" target in V1.
I believe you can specify requirements on it, and they
are really meant for depends only. Similarly, <optimization> might
have absolutely no effect on linker, requirements in

lib biglib : lib1 lib2 : <optimization>maximum ;

mostly affect dependencies.

>>It you're talking about requirements, it's not that strange:
>>
>> lib a : a.cpp : <shared>true ;
>>
>>Here, requirements are really requirements: "a" will *always* be built as
>>shared library. Looking at
>>
>> exe b : a b.cpp : <static>true ;
>>
>>Then <static> would be true requirements if it affected "b", but it does not.
>>However, it is propagated to a. But then, "a"'s requirement cause it to
>>be built as shared.
> 
> 
> OK, I see your point. However, I don't see any way of expressing a
> shared library which links to the static runtime, or some other
> library statically.

lib lib1 : other_lib/<shared>false ;

The case of static runtime is indeed tricky, but that's another issue -
we still don't know how we want to affect runtime link.

>>It's precisely what I mean by "not hard requirement". I belive that
>>"hard requirement" in V2 are "link-incompatible" properties.
> 
> 
> Yep, I think you're right.
> 
> 
>>For example <optimization> is *not* hard requirement, as I see it. If I set it
>>on exe, it does not mean that dependencies cannot be build with different 
>>values. For example
>>
>> lib a : a.cpp : <optimization>space ;
>> exe b : b.cpp a : <optimization>speed ;
>>
>><shared> is not different.
> 
> 
> It is different in two ways:
> 
> 1. It could be used in a context where it _cannot_ apply to the target
> being built (i.e. the exe above). It's a fine generalization, but
> it could be confusing to users (as it was for me).
> 
> 2. You sometimes want to express that it _must_ be one way for a given
> target, and _different_ for (some of) its dependencies.
> 
> I don't think #1 is too serious; in fact I like the elegant
> generalization. However, #2 does seem serious to me.

You (well, probably I) sometimes want to specify that <optimization>
myst be one way for a given target and different for some dependencies.
In fact, that requirement lead me to implement the feaute to specify
requirement together with target reference. Compare

exe a_test : a.cpp lib1/<variant>release : <variant>debug ;
exe b : b.cpp lib2/<shared>false : <shared>true ;

The first case is not as odd as it might seem. E.g. "a" is a
test binary (and release version of it has no asserts). And
"lib1" is very well tested, but produces tons of trace messages
in debug version.

- Volodya