
BoostBuild : 
Subject: Re: [Boostbuild] feature, properties, variants, and all the rest
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 20170728 21:09:16
AMDG
On 07/28/2017 02:22 PM, Stefan Seefeld via Boostbuild wrote:
> On 28.07.2017 15:48, Steven Watanabe via Boostbuild 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:
"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."
>>> Of course, looking at a single conditional statement (as in your
>>> original example), there always is an implied order. But in realworld
>>> scenarios that may not be the case (if for example configure checks are
>>> combined with multiple prerequisite targets that all contribute to the
>>> final propertyset 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.
> 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.
>> 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.
Alright, let's make another attempt to describe the
expected behavior:
evaluateincontext(P, C) = evaluate conditional properties C in the
context of propertyset P and return the added properties. This
is the basic iteration step. It doesn't do anything fancy.
P1.refine(P2) = Combine 2 propertysets P1 and P2. Properties from P2
will override those in P1.
I = initial properties
R = result properties
C = conditional properties
The key property of the algorithm is that:
I.refine(evaluateincontext(R, C)) = R
In Christ,
Steven Watanabe
BoostBuild 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