Boost logo

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:
> 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
> (
> <>).
> 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
> <>.

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 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,

Boost-testing list run by mbergal at