On Wed, Aug 9, 2017 at 3:11 PM, Raffi Enficiaud via Boost
Le 09.08.17 à 23:34, Vinnie Falco via Boost a écrit : I was randomly clicking on a link, like this one:
http://www.boost.org/development/tests/develop/developer/output/teeks99-09-m...
This has nothing to do with the test framework, it just happens that suite.hpp is one of the first files included and therefore the first to generate an error. The problem in this case is that the toolchain is using Visual Studio 2012 which does not have sufficient support for C++11, and in particular insufficient support for "noexcept" as indicated here: https://msdn.microsoft.com/en-us/library/hh567368.aspx
For preventing running the tests on unsupported compilers, you may use b2 features, which will clear out some of the columns: http://www.boost.org/build/doc/html/bbv2/overview/targets.html#bbv2.overview...
Thanks, this is helpful!
When is now and when is later? If now means boost 1.65, then yes, this is not possible. If this is 1.66, I would say it is not such a big deal.
My schedule for 2017 is very tight. There is a backlog of Beast issues that I want to address for its debut in 1.66.0 as some of them may introduce API changes which I would rather do now instead of after putting out the first non-beta version. Boost.Asio is going to be updated at some random time in 2017 and I will have to quickly port Beast for those changes. And Beast needs to have some time without any changes prior to the freeze for 1.66.0, so that any lingering defects can be flushed out. There's a fair amount of test code and it makes heavy use of coroutines, threads, and helper classes (Beast's unit test framework is class-driven where each test is represented by a derived class). I have in mind to try out the lightweight framework after 1.66.0, which will be part of a larger push to bring the coverage as close to 100% as possible but I don't have the resources for it this year. So I am very much stuck with what I have. So far there is nothing in the build output to suggest that the testing framework is at fault but I will keep a close eye on it. What I'm looking for is the secret document that I am SURE is stashed away somewhere on a Google Drive account, or maybe a USB stick, which explains all of the common errors that happen in the Boost test environment and how they might be worked around. For example, that early versions of the standard library do not have full support for std::allocator_traits even though they claim to. I've since fixed that issue here: https://github.com/boostorg/beast/pull/725/commits/017510215122c013579f6c746... But as you know the turnaround time on cycling a library through the tests is quite long, so if I could get a copy of that document which has solutions to common problems ahead of time, then I could save several length iterations. Thanks