Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-07-28 21:09:16
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:
> 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 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.
> 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
Alright, let's make another attempt to describe the
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.
P1.refine(P2) = Combine 2 property-sets 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(evaluate-in-context(R, C)) = R
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