Re: [boost] [build] [config] check_target_builds and feature.subfeature composition

Subject: Re: [boost] [build] [config] check_target_builds and feature.subfeature composition
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-01-24 19:55:54

On 1/24/2017 9:13 AM, Stefan Seefeld wrote:
> On 24.01.2017 03:30, John Maddock wrote:
>>
>>>> Yes I have, I brought it up, nothing happened. I stopped using
>>>> check_target_builds.
>>>>
>>>    The problem is that check_target_builds tries to
>>> guess which features are important, and does it
>>> badly (via a hard-coded list).
>>
>> IMO this is just plain wrong - any command line change could change
>> the behaviour of the compile - I would rather loose the caching (which
>> itself is problematic at times) that have it yield the wrong answer.
>
> Allow me to tie this back to an earlier conversation:
>
> It seems this issue arises because b2 allows multiple build variants to
> be built at once, so (at least theoretically) each would need to run its
> own set of config checks.

You don't need multiple build variants to generate the problem. Just 
build with a toolset for a compiler(-version) with a subfeature that 
sets -std=c++03, and then subsequently build with a compiler(-version) 
with a subfeature that sets -std=c++11. The check_target_builds uses the 
same cached value for both because it only distinguishes between 
compiler(-version) and not sub-feature.

> I understand that there are features that may take on different values
> within a single build, but to open that door widely and let multiple
> feature values be set at build time just makes the whole process so much
> more complex. Wouldn't there be a way to simplify this to get the
> complexity in check ?
> Alternatively, config checks need to become (intermediate) build targets
> by themselves, and "caching" would need to be handled the same as for
> any other target (such as object files).