|
Boost-Build : |
Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-29 01:42:08
On 28.07.2017 20:39, Steven Watanabe via Boost-build wrote:
> AMDG
>
> 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 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 ? Or is it
evaluated in multiple contexts ?
By what logic is its value being propagated into C's property set (if at
all) ?
Thanks,
Stefan
-- ...ich hab' noch einen Koffer in Berlin...
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