On 6/21/2015 5:19 PM, Peter Dimov wrote:
I have, in my user-config.jam,
using gcc ;
feature.subfeature toolset gcc : std : cxx0x cxx11 cxx1y cxx14 : optional composite propagated ;
feature.compose toolset-gcc:stdcxx0x : <cxxflags>-std=c++0x ; feature.compose toolset-gcc:stdcxx11 : <cxxflags>-std=c++11 ; feature.compose toolset-gcc:stdcxx1y : <cxxflags>-std=c++1y ; feature.compose toolset-gcc:stdcxx14 : <cxxflags>-std=c++14 ;
using clang : : : <cxxflags>-Wno-variadic-macros <cxxflags>-Wno-c99-extensions ;
feature.subfeature toolset clang : std : cxx0x cxx11 cxx1y cxx14 : optional composite propagated ;
feature.compose toolset-clang:stdcxx0x : <cxxflags>-std=c++0x ; feature.compose toolset-clang:stdcxx11 : <cxxflags>-std=c++11 ; feature.compose toolset-clang:stdcxx1y : <cxxflags>-std=c++1y ; feature.compose toolset-clang:stdcxx14 : <cxxflags>-std=c++14 ;
This allows me to use toolset=clang (without -std) and toolset=clang-cxx11 (with -std=c++11).
The 'requires' rule however caches the results of the configuration check when I run with toolset=clang, and then when I rerun with toolset=clang-cxx11, it uses the cached values, which is wrong.
The problem is that running configuration checks for all unique set of properties is quite wasteful. Say, the 'link' property usually has no effect on architecture and address-model, and if we re-run architecture/address-model checks for both static and shared variants, the result will be correct, but we'll do a lot of unnecessary checks and produce lots of unnecessary output. It does not seem possible to avoid having some 'key' properties used for configuration checks? - Volodya