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

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-29 00:00:00

On 28.07.2017 19:11, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 07/28/2017 04:38 PM, Stefan Seefeld via Boost-build wrote:
>> OK, now I get it !
>> I hope it is becoming clear that these semantics are far from obvious,
>> and it is important to spell them out somewhere. (It's of course
>> possible that I'm just very slow in understanding, but I doubt these
>> things are obvious to anyone who isn't intimately familiar with the
>> implementation itself.)
>>
>   These semantics are actually the most sane
> if you're thinking about it in terms of abstract
> semantics instead of considering a specific
> implementation.  The problem is that it's easy
> to assume the obvious implementation and deduce
> the semantics from that (which is wrong in this case).

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.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...