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 19:48:44

AMDG

On 07/28/2017 12:59 PM, Stefan Seefeld via Boost-build wrote:
> 
> I'm actually thinking of cases where (assuming multiple passes) a single
> conditional may yield different (mutually exclusive) results. Consider
> 
> 1) if defined(A) define(B) else define(C)
> 2) if not defined(B) define(A)
> 

Do you have an actual case that looks like this,
or is it purely theoretical?

> for which the final state depends on whether you start the evaluation
> loop with 1) or with 2). It seems impossible for b2 to flag this as
> wrong, and it may even be right, as long as a specific order of
> evaluation of the conditionals as guaranteed. But in the absence of that
> order, it simply is undefined.
> 

The order of evaluation is irrelevant, because
the algorithm actually works like this:

eval-conditions(initial, conditionals) {
  current = initial
  repeat(conditionals.size() + 1) {
    added = [eval-one(c, current) for c in conditionals]
    new-result = initial + added
    if current == new-result
      return new-result
    current = new-result
  }
  handle error
}

It evaluates all of the conditions independently
in each iteration and combines the results with
the original properties.  (It's important to use the
original properties rather than the previous iteration
to guarantee that the result is consistent.)

> 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

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

In Christ,
Steven Watanabe