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: Robert Ramey (ramey_at_[hidden])
Date: 2016-11-12 14:44:45

I spent a little time investigating this issue and a couple of things 
have occurred to me.

I still after all these years can't get the hang of boost build syntax - 
but I still tried to look through how these "requires" statements are 
implemented.  I found the files in config/test.  Here's one

#include <forward_list>

namespace boost_no_cxx11_hdr_forward_list {

int test()
{
   std::forward_list<int> l(2u, 2);
   return *l.begin() == 2 ? 0 : 1;
}

}

Now it seems to me that this really should be:

#include <config.hpp>
#include <forward_list>

namespace boost_no_cxx11_hdr_forward_list {

int test()
{
   #ifdef BOOST_NO_CXX11_HDR_FORWARD_LIST
     return 1;
   #endif

   std::forward_list<int> l(2u, 2);
   return *l.begin() == 2 ? 0 : 1;
}

}

I'm thinking that this would address the situation whereby 
<forward_list> exists - but the tests are built with std=C++03 (or no 
switch at all for many compilers).  The idea is that this would ripple 
up to the top level and prevent inappropriate tests from being run.

The test matrix shows a lot of places where test_forward_list is being 
run (and passing FWIW) on compilers which look like they are invoked in 
such a way that they don't support C++11+.  This is very, very confusing 
and makes it unclear just what the test system results actually mean and 
how they are meant to be used.

Another issue:

The mngw tests are all failing to compile.  (though it seems that the 
libraries are being built.) This seems to be because that the file 
system library library needs BOOST_NO_STD_WSTRING in order to build. So 
in this case, it would likely be better just to not run the tests for 
the wide character versions of archives at all.  For the Nth time, I 
read over the boost build syntax and I can't figure out how to implement 
this.  I'm happy to read any suggestions.  Another idea would be to 
remove dependency of the serialization library tests on the boost 
filesystem library.  I used to be this way, but someone "helpfully" 
improved the test code so that it now depends upon this library. I left 
this in as it did seem to be an improvement.  So a bjam solution would 
likely be better.  I'm all ears.

Of course it's not all that clear why boost.filesystem should depend 
upon wstring when it could conjure up basic_string<wchar_t> but I can't 
go everywhere.

Robert Ramey