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

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-07-28 21:09:16

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."

>>> 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
intermediate context.

  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.

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

In Christ,
Steven Watanabe