Re: [Boost-testing] BJam and options for compiler versions >= x

Subject: Re: [Boost-testing] BJam and options for compiler versions >= x
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-03-27 08:31:58

Le 25/03/15 17:45, Rene Rivera a écrit :
> On Wed, Mar 25, 2015 at 11:38 AM, John Maddock
> <jz.maddock_at_[hidden] <mailto:jz.maddock_at_[hidden]>> wrote:
>
>
>
>     On 25/03/2015 14:58, Raffi Enficiaud wrote:
>
>         Hi,
>
>         I have a test that should compile the code with C++11 options.
>         For eg. GCC, I have a rule like this, which I do not like
>
>         <toolset>gcc-4.4:<cxxflags>-__std=c++0x
>         <toolset>gcc-4.5:<cxxflags>-__std=c++0x
>         <toolset>gcc-4.6:<cxxflags>-__std=c++0x
>         <toolset>gcc-4.7:<cxxflags>-__std=c++11
>
>         I would like to know:
>         - if there is a better way to do this
>         - if it is possible to set the option "-std=c++11" for compilers
>         with versions >= 4.7
>
>     I don't think we have a toolset option for that - though it sure
>     would be useful!
>
>     The way I do it, is not to second guess / change what options the
>     test runner is using, but either:
>
>     * Make the test a no-op if the C++11 features used aren't present, or:
>     * Use the Boost.Config build checks to disable the test altogether
>     if the features you require aren't available
>     (http://www.boost.org/doc/__libs/1_57_0/libs/config/doc/__html/boost_config/build___config.html
>     <http://www.boost.org/doc/libs/1_57_0/libs/config/doc/html/boost_config/build_config.html>).
>
>     The point of doing things this way, is it "works" for compilers
>     other than GCC, including those that don't have switches to select
>     the language dialect (ie the features either work or they don't).
>
>
> +1
>
> But.. I would highly recommend that you do both of the above. The first
> one makes it so that someone not using BB can make use of the test (for
> whatever reason they like). And the second one removes it from the test
> results table so that it reduces the noise.
>
> But if that is not what you are after you can also use the Boost Predef
> checks to set those options. As they support more than just a specific
> compiler version. See the docs for how to use that here
> <https://rawgit.com/boostorg/predef/develop/doc/html/predef/check_utilities.html>.
>
>

Thank you both for your answers (and sorry for the late reply).

So basically, requirements is the way to go there. Right now, I have 
some defines in the code that indicate what of the new functionalities 
are enabled for the current compiler, based on what boost.config tells us.
I use those defines to enable/disable the specific parts, which is close 
I think to the suggestion of John (no-ops).

The way I see these things are:
- seeing in the dashboard that a test is not enabled for a specific 
compiler I would say is very informative. This is why I prefer the 
solution with requirements instead of the no-ops
- splitting the tests into smaller tests, C++03 and C++11, is also the 
way to go. I recently figured out that the Jamfile for the tests was not 
configured properly, and I missed some issues with specific compilers 
because they were compiling without the -std=C++11

I guess at some point boost.test maintainers should provide a way to 
run.py to understand the content of the tests, and fill the dashboard 
with the one test-cases per line instead of a test executable per line.

Thanks again,
Best,
Raffi