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-28 21:49:03

On 28.07.2017 17:09, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 07/28/2017 02:22 PM, Stefan Seefeld via Boost-build wrote:
>> On 28.07.2017 15:48, Steven Watanabe via Boost-build wrote:
>>> The order of evaluation is irrelevant, because
>>> the algorithm actually works like this:
>>>
>>> <snip>
>> Ah ! I think this is rather important (the behaviour, not the
>> implementation), and should be part of the documentation. Or perhaps it
>> is, and I just haven't found it ?
> There's an abstract description of the behavior here:
>
> http://www.boost.org/build/doc/html/bbv2/reference/buildprocess.html#bbv2.reference.buildprocess.common
>
> "5. If requirements include a conditional property, and
> condiiton [sic] of this property is true in context of common
> properties, then the conditional property should be in
> common properties as well."

Hmm, that's a bit obscure. (In hindsight, i.e. after your explanations
in this thread, it makes sense, but I would never have been able to come
to that conclusion without it.)
>>>> Of course, looking at a single conditional statement (as in your
>>>> original example), there always is an implied order. But in real-world
>>>> scenarios that may not be the case (if for example configure checks are
>>>> combined with multiple prerequisite targets that all contribute to the
>>>> final property-set for a given target.
>>>>
>>>> How would b2 handle this ?
>>>>
>>> If you start from no properties defined, then there
>>> is no way to satisfy these constraints:
>>>
>>> A -> (1) requires B
>>> A B -> B is present, so (2) shouldn't add A
>>> A C -> (1) requires B, not C
>>> A B C -> C is extraneous
>>> B -> (1) doesn't add B without A
>>> B C -> There is no reason for B
>>> nothing -> (2) should add A
>>> C -> (2) should add A
>> I don't understand the syntax you use here, and therefore the meaning.
>> What do you mean by "A -> (1) requires B" ?
> On the left hand side is the possible result properties.
> The right side is the reason that this set is not a valid
> result.  I listed all 8 combinations of A, B, and C.

OK, thanks.
>> If I follow your rule (about individual constraints being evaluated
>> individually in each iteration), I get this:
>>
>> 0. start with no properties defined
>> 1. iteration: add C (from first condition), add A (from second condition)
>> 2. iteration: keep C, A (from first iteration), add B (from first condition)
>>
>> Have I misunderstood the algorithm ?
>>
> Yes.  In iteration 2, there is no keep C, A.
Now you lost me. :-)
What does "iteration" mean if not to continue with the state from the
previous round ?
(The line "current = new-result" in your loop does exactly that, does it
not ?)
>>> Therefore, this is correctly an error.
>>> (Note that anything that contains B would
>>> be consistent if we allow properties to appear
>>> out of the blue, which we don't).
>> Can you elaborate on what you mean by "out of the blue", and thus what
>> is not allowed ?
>>
>   What I mean is that every property that appears in
> the result must have a reason for being there, either
> because it is in the initial set of properties or
> because it was added by a conditional as evaluated
> in the context of the result, not some indeterminate
> intermediate context.

What do you mean by "intermediate context" ? Would that be the iteration
2 above, where I wrote "keep C, A" ? It sounds like there lies a
fundamental misunderstanding I have.

>   Alright, let's make another attempt to describe the
> expected behavior:
>
> evaluate-in-context(P, C) = evaluate conditional properties C in the
>   context of property-set P and return the added properties.  This
>   is the basic iteration step.  It doesn't do anything fancy.

Return the added properties only, or return the union of the original
properties plus the added ones ? (I think you mean the latter, but given
the above, I'd rather spell it out for avoidance of doubt.)
> P1.refine(P2) = Combine 2 property-sets P1 and P2.  Properties from P2
>   will override those in P1.
OK.

> I = initial properties
> R = result properties
> C = conditional properties
>
> The key property of the algorithm is that:
> I.refine(evaluate-in-context(R, C)) = R

Right, that much is clear (I think).
        Stefan

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