Subject: Re: [Boost-build] adding tests conditional on compiler's C++11 support
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2016-11-11 13:06:02
On 11/11/2016 10:15 AM, Robert Ramey wrote:
> On 11/11/16 7:04 AM, Steven Watanabe wrote:
>> I'm guessing that the problem is that config.requires
>> directly uses the tests for Boost.Config. The macros
>> are supposed to be in sync with the tests, so I think
>> this is a bug in Boost.Config.
> I've considered that. But if that's the case, then the problem should
> never occur.
> I've looked at the test matrix for config. Looking at row labeled
> config_info and columns Sandia-darwin-c++11/darwin 4.2.1 and
> Sandia-darwin/darwin 4.2.1. Note the only difference is the C++11 switch.
> The outputs for config_info differ in that the one using the C++11 does
> not have BOOST_NO_CXX11_HDR_FORWARD_LIST while the one not using the
> C++11 switch does. This is as it should be.
> But b2 is invoking test_forward_list even when config_info suggests it
> shouldn't. Is is possible that b2 is invoking using the config_info
> test results generated with with the C++11 switch?
Not possible. They're on separate non-incremental
runners, which means that each one runs in an
independent clean build environment.
> The "requires" would
> mean that test_forward_list would be invoked. But when it actually is
> (with the BOOST_NO_CXX11_HDR_FORWARD_LIST being set), the compilation
> aborts with #error.
> This would not surprise me. When I run C++11 tests, I have to add a c++
> switch to the compiler command line. I do this in my user_config.jam
> with the statement
> using darwin : 6.2~11 : /hpc-6.2/usr/local/bin/g++ :
> <cxxflags>"-std=c++11" <define>"BOOST_LIB_DIAGNOSTIC=1" ;
> I don't know how the test matrix does it.
The test matrix does whatever the person running
the tests wants, which is probably similar to
> But in any case I don't see
> how bjam/config would "know" how to set the switch when it does it's
> thing. I don't know if there is a "global" setting of compiler version.
> It think there is something fundamental missing here - at at least that
> I'm missing.
> It's also odd that it seems to occur in this one special case. I don't
> know what to make of this.
I'm guessing that forward_list actually exists
and is usable in C++03 (at least to the minimum
required by boost_no_hdr_cxx11_forward_list.ipp),
but that this is not recognized by the macros
in Boost.Config (which are determined strictly
by checking predefined macros).
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk