Re: [Boost-build] feature, properties, variants, and all the rest

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

AMDG

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