Quantcast

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

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

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

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

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