Re: [Boost-build] adding tests conditional on compiler's C++11 support

Subject: Re: [Boost-build] adding tests conditional on compiler's C++11 support
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-09-28 16:53:32

On 28.09.2016 15:18, Steven Watanabe wrote:
> AMDG
>
> On 09/28/2016 12:34 PM, Stefan Seefeld wrote:
>> what is the boost.build way to add a set of tests to my (Boost.Python)
>> test suite only if the given compiler supports C++11 ? To break that
>> down into two questions:
>>
>> * Is there a Boost.Build flag I can check for that indicates whether the
>> current compiler supports C++11 ?
>>
>> * How can I conditionalize the adding of tests to my test suite based on
>> that flag ?
>>
> Try using config.requires:
> http://www.boost.org/libs/config/doc/html/boost_config/build_config.html

Thank you, that seems to work, sort of. I ran into an oddity, though:
To test, I'm invoking `b2 cxxflags=-std=c++03` (with my toolchain being
gcc 6.2, i.e. with C++11 support enabled by default).
I had previously built the library (Boost.Python) without passing any
extra flags (i.e. just `b2`), and am now running tests within the
`test/` subdirectory. I have added a C++11-specific test like this:

[ bpl-test shared_ptr
  : # sources
  : [ requires cxx11_smart_ptr ]
]

and even if I run `b2 cxxflags=-std=c++03` the test is being built. This
begs the question: how exactly does Boost.Build determine the value of
the `cxx11_smart_ptr` flag ? Or rather, when ?
When I recompile Boost.Python with `b2 cxxflags=-std=c++03` and run the
tests again the above test is no longer compiled. This suggests that
Boost.Build stores the cxx11_smart_ptr value with the library build,
rather than computing it with each compiler invocation. Is that right.
And if so, is that really the right way / time to compute it ? (I'm
thinking it might be better to compute each time the compile is invoked,
but I wonder whether I'm overlooking some rationale for the current choice.)

Thanks,
        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...