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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Stefan Seefeld-2
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.
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).

Regards,
        Stefan


--

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Edward Diener-3
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).


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Stefan Seefeld-2


On Jan 24, 2017 8:00 PM, "Edward Diener" <[hidden email]> wrote:
>
> 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).

[…]

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

To me that's two build variants, at least conceptually. How else would you combine builds with two ABI-incompatible flags ?

   Stefan


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Loading...