Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-07-28 23:11:26
On 07/28/2017 04:38 PM, Stefan Seefeld via Boost-build wrote:
> On 28.07.2017 18:27, Steven Watanabe via Boost-build wrote:
>> 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.)
These semantics are actually the most sane
if you're thinking about it in terms of abstract
semantics instead of considering a specific
implementation. The problem is that it's easy
to assume the obvious implementation and deduce
the semantics from that (which is wrong in this case).
> 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.
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