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-23 17:38:55

On 1/22/2017 12:58 PM, Edward Diener wrote:
> The Boost library config uses the check_target_builds rule to provide
> build time feature testing. Other Boost libraries use config checks in
> their own build and test jamfiles.
>
> I have found that this works reliably when a particular toolset is used
> in a normal manner. However when using the feature.subfeature and
> feature.compose rules to extend the toolset-version designation with a
> subfeature, such that the toolset designation now becomes
> toolset-version-subfeature, the use of the check_target_builds rule does
> not work as expected. In particular the individual check_target_builds
> rule results are put into a subdirectory based on the toolset-version
> and not based on the toolset-version-subfeature when toolset subfeature
> composition is used. I also suspect that the cached value reflects
> setup. This causes wrong results in tests where the toolset designation
> uses subfeatures, and a library's jamfile is using config and/or predef
> checks.
>
> As an example
>
> My toolset designation looks like:
>
> using gcc : 6.3 : some_path ;
> feature.subfeature toolset gcc : cxxstd : c03 c11 c14 c17 : optional
> composite propagated ;
> feature.compose <toolset-gcc:cxxstd>c03 : <cxxflags>-std=c++03 ;
> feature.compose <toolset-gcc:cxxstd>c11 : <cxxflags>-std=c++11 ;
> feature.compose <toolset-gcc:cxxstd>c14 : <cxxflags>-std=c++14 ;
> feature.compose <toolset-gcc:cxxstd>c17 : <cxxflags>-std=c++1z ;
>
> A library's test looks like:
>
> import ../../config/checks/config : requires ;
> run some_test.cpp : : : [ requires cxx11_hdr_forward_list ] ;
>
> If I run some some_test with toolset=gcc-6.3-c03, the config result for
> checking if forward list is supported is put into a subdirectory
> reflecting the toolset-version while the test result will be put into a
> subdirectory reflecting the toolset-version-subfeature. Subsequently if
> I run some_test with toolset=gcc-6.3-c11 the config result is taken from
> the subdirectory reflect the toolset-version even though whether the
> forward list is supported or not depends very much on the subfeature I
> am designating as part of the toolset. This naturally causes incorrect
> results for the test.
>
> Is this a known problem ? Is it a problem with Boost Build or is it a
> problem with how config uses the check_target_builds rule ? I have run
> into this problem extensively in my testing once I started to use the
> feature.subfeature ability of Boost Build.

Ping !

Has no one else encountered the same problems I have encountered using 
the feature.subfeature facility in Boost Build ? I recall Peter Dimov 
saying he used that Boost Build facility, which is why I looked into it, 
and I am guessing others use it. To me using this facility is just 
broken because not only does config use the check_target_builds but 
predef uses it also ( my non-Boost cxxd library also uses it ). So any 
Boost jamfile using config or predef to determine what should be built 
is subject to the same problem I encountered when using the 
feature.subfeature facility. I am a bit surprised that this is a 
non-issue with everyone else on this mailing list.