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

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-28 22:38:07

On 28.07.2017 18:27, Steven Watanabe via Boost-build wrote:
> 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. 

Oooooh ! :-)

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

OK, now I get it !

I hope it is becoming clear that these semantics are far from obvious,
and it is important to spell them out somewhere. (It's of course
possible that I'm just very slow in understanding, but I doubt these
things are obvious to anyone who isn't intimately familiar with the
implementation itself.)

I'll continue to try to reimplement something similar in Faber (my
Boost.Build Python port: https://github.com/stefanseefeld/faber), while
at the same time trying clarify either how to specify the semantics in
more obvious ways, or, if necessary, change the semantics slightly to
become simpler to express.

Thanks very much for walking me through this !

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...