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