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:cxxstdc03 : <cxxflags>-std=c++03 ; feature.compose toolset-gcc:cxxstdc11 : <cxxflags>-std=c++11 ; feature.compose toolset-gcc:cxxstdc14 : <cxxflags>-std=c++14 ; feature.compose toolset-gcc:cxxstdc17 : <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.