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 22:27:57

AMDG

On 07/28/2017 03:49 PM, Stefan Seefeld via Boost-build wrote:
> On 28.07.2017 17:09, Steven Watanabe via Boost-build wrote:
>> 
>> On 07/28/2017 02:22 PM, Stefan Seefeld via Boost-build wrote:
>>> 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 ?)

  In each iteration, the current state is used to
evaluate the conditionals.  The result of the
conditionals is then added to the /original/ state
to create the new state.  Maybe I misunderstood
what you were saying, but what actually happens in 2 is
state = C, A (from first iteration), added = B (from first condition),
A (from second condition), next-state = A B (original state + added)
The old state of [C A] is discarded.  Then we continue with
3. state = [A B], added = B (1st condition), next-state = B
4. state = [B], added = C (1st condition), next-state = C
5. state = [C], added = C (1st condition), A (2nd condition), next-state
= A, C

and we're back where we started.  This will then
give an error because it failed to converge.

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

I think so.

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

  No, I mean the former (exactly as stated).
This function is just evaluating the conditionals
and nothing else.  Merging is handled by refine.

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

In Christ,
Steven Watanabe