Re: [jamboost] Re: runtime-link

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 11:29:23

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> 
>> 
>>>David Abrahams wrote:
>>>
>>>
>>>> 2. Is this feature meant to express a preference or a hard
>>>> requirement?
>>>
>>>Preference. You must be able to set it globally, and not to fight
>>>with libraries that are available in only one variant.
>> 
>> 
>> 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.

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

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

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