Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-07-28 22:27:57
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.
>> 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).
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