Boost logo

Boost-Build :

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-07-29 02:15:41


On 07/28/2017 07:42 PM, Stefan Seefeld via Boost-build wrote:
> On 28.07.2017 20:39, Steven Watanabe via Boost-build wrote:
>> On 07/28/2017 06:00 PM, Stefan Seefeld via Boost-build wrote:
>>> Indeed. I'm still not entirely sure the semantics are fully unambiguous.
>>> Consider this use-case:
>>> Target A is a config check, which (conditionally) defines property a.
>>> Target B, depending on A, defines property b. Target C depends on A and B...
>>> So, a is evaluated in the context of an empty property-set, while b is
>>> evaluated in the property-set consisting of a. The result is then passed
>>> on to C.
>>> What happens if B does not depend on A ? That would mean that that
>>> property b is evaluated in an empty property-set (just as a itself),
>>> rather than in the context of a, and thus might lead to a different
>>> property-set passed on to C.
>>> Correct ?
>>> This is just slightly surprising, as 'B depends on A' merely seems to
>>> imply an order of execution (A before B), while, if the above is
>>> correct, this actually influences the property-set seen by C.
>> I'm not sure that I follow. When you say
>> that target A defines property a, do you
>> mean that a is in the usage requirements of A?
> Sorry, no. A being a config check, I meant that the value of property a
> depends on the result of A's update.
>> Or do you mean that B uses A inside check-target-builds?
> For B it shouldn't matter how it uses a, just that a (which is a
> conditional property) needs to be evaluated into the property set seen
> by B.

  In other words, yes, it uses check-target-builds, as
this is the only way for properties to change based
on whether a target was successfully updated.

> In fact, having reformulated it like this, I think I can rephrase my
> question:
> If a is evaluated, is it being evaluated once into B's property set and
> then propagated to everything else that depends on B ?

  Properties in the requirements of B are never propagated
to anything that depends on B. They are evaluated
once when building B and then any `propagated` properties
are passed on to any targets that B depends on.

> Or is it
> evaluated in multiple contexts ?

  Conditionals defined on B are only evaluated in the
context of B. They are always resolved before
passing them on to other targets.

> By what logic is its value being propagated into C's property set (if at
> all) ?

The requirements of B will never directly affect C.

Okay, example time:

feature a : on : optional ;
obj A : a.cpp ;
obj X : X.cpp ;
lib B : X Y.cpp : [ check-target-builds A : <a>on ] ;
exe C : B ;

Assume that A builds successfully.
Y.o and B.a will be built with <a>on (whatever that does).
X.o and C will /not/ have <a>on.

  If we change the definition of a to
feature a : on : optional propagated ;
then X.o will be built with <a>on. (propagated
causes a feature to be passed on to dependents)

  If A does not build successfully, then <a>on
will not be used for any target.

  Is this anything like what you had in mind,
or am I totally misunderstanding?

In Christ,
Steven Watanabe

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at