Boost logo

Boost :

Subject: Re: [boost] [Config] Announce: New Build time configuration feature
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-06-05 14:58:03

On 6/5/2014 2:01 PM, John Maddock wrote:
> In develop only is a new feature to make configuring targets at build
> time easier, from the docs:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> There are times when you want to control whether a build target gets
> built or not, based on what features the compiler supports. For example,
> suppose you have a test file "test_constexpr_128.cpp" which requires
> three key features in order to build:
> * The constexpr keyword as detected by BOOST_NO_CXX11_CONSTEXPR.
> * User defined literals, as detected by
> * The __int128 data type, as detected by BOOST_HAS_INT128.
> Clearly we know that if these features are not supported by the
> compiler, then there's simply no point in even trying to build the test
> program. The main advantages being:
> * Faster compile times - build configuration uses lightweight tests
> the results of which are also cached.
> * Less noise in build output - there's no reason to be faced with
> pages of template instantiation backtrace if we know the file can never
> compile anyway.
> * Less noise in the online test results - the test will show up as
> blank, rather than as a fail in the online test matrix.
> * A better experience for end users building all of Boost, if those
> libraries which can not be built for the current target compiler are
> simply skipped, rather than generating pages of error output.
> Returning to our example, the test case is probably executed in it's
> Jamfile via the "run" rule:
> run test_constexpr_128.cpp ;
> We now need to make this target conditional on the necessary features.
> We can do that by first importing the necessary rule at the start of the
> Jamfile:
> import path-to-config-lib/checks/config : requires ;
> Assuming that the test case is in the usual directory:
> libs/yourlib/test
> then the import rule will actually be:
> import ../../config/checks/config : requires ;
> Then add a "requires" rule invocation to the requirements section of the
> target:
> run test_constexpr_128.cpp
> : : : #requirements:
> [ requires cxx11_constexpr cxx11_user_defined_literals int128 ] ;
> Notice that multiple arguments can be added to the requires rule, and
> that these are always the same as the Boost.Config macro name, but in
> lower case and with the boost_no_ or boost_has_ prefix removed.
> When building the above example, you will see at the start of the build
> process the results of the configuration, for example GCC in C++11 mode
> gives:
> - Boost.Config Feature Check: int128 : yes
> - Boost.Config Feature Check: cxx11_constexpr : yes
> - Boost.Config Feature Check: cxx11_user_defined_literals : yes
> That's all there is to this handy feature, should at any time you be
> unsure of the feature-test names you can pass to the "requires" rule,
> then search for the Boost.Config macro of interest in
> libs/config/checks/Jamfiles.v2, and the name of the feature check will
> follow it.
> And finally, this feature is built around the Boost.Build built in rule
> check-target-builds which can be used to perform more generalized
> build-time feature testing. The checks in this library are provided as a
> convenient shorthand without the need for you to write the test cases
> yourself.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Let me know what you think, and enjoy :-)

Without trying this out yet, the idea is fantastic ! Bravo ! Trying to
figure out anything in Boost Build is always torture for me due to the
utter lack of low-level documentation in Boost Build of how to do things
that are not mainstream in Boost Build.

Boost list run by bdawes at, gregod at, cpdaniel at, john at