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 18:15:38

AMDG

On 07/28/2017 11:25 AM, Stefan Seefeld via Boost-build wrote:
> Hi Steven,
> 
> I'm coming back to a discussion from a long time ago...
> 
> On 23.12.2016 16:39, Steven Watanabe wrote:
>> Conditional properties are evaluated when
>> processing target requirements.  The actual
>> algorithm evaluates all conditionals repeatedly,
>> until it reaches a fixed point.
>>
>> Ex:
>>
>> rule c ( properties * )
>> {
>>   if <variant>debug in $(properties)
>>   { return <define>DEBUG }
>> }
>>
>> Requirements:
>> <toolset>msvc:<link>shared <link>shared:<variant>debug <conditional>@c
>>
>> Initial properties:
>> - <toolset>msvc
>> Round 1:
>> - <toolset>msvc <link>shared (Other conditionals are not satisfied)
>> Round 2:
>> - <toolset>msvc <link>shared <variant>debug
>> Round 3:
>> - <toolset>msvc <link>shared <variant>debug <define>DEBUG
>> Round 4:
>> - <toolset>msvc <link>shared <variant>debug <define>DEBUG
>> (Identical to round 3, terminating the algorithm)
> 
> This describes a (domain-specific) constraint solver. Are there any
> chances this could lead to undefined behaviour (for example if the order
> in which the conditionals are evaluated influences the outcome) ?

  I suppose that it's theoretically possible,
but I've never seen it happen nor have I heard
any reports of it.  In order for this to occur
you'd need to have a cycle.
  The normal uses of conditionals are
a) add a compiler flag for a specific compiler (normal conditional)
b) add include/library paths if they are found (ac.check-library)
c) disable a target for broken compilers (config.requires)
d) add #defines to control dllexport/visibility (normal conditional)
e) force a specific build variant for some compiler (normal conditional)
which results in properties being resolved in this order:
toolset -> link/runtime-link/variant -> cxxflags/linkflags

> What
> are the odds that it will result in an infinite loop ?

  It terminates with an error if it fails to
converge after a number of iterations equal
to the number of conditionals + 1.

> Or does the
> design necessarily lead to a stationary state ?

  It's guaranteed to converge in the absence of cycles.
If you do something like this you'll have a problem:
<toolset>gcc:<link>static <link>static:<toolset>msvc
<toolset>msvc:<link>shared <link>shared:<toolset>gcc

> What about invalid
> (conflicting) constraints ?
> 

That should be an error.

In Christ,
Steven Watanabe