Boost Testing :
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:
> 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
> 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
> 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).
> 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
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.