Re: [boost] Best Practices for Surviving the Boost Test Gauntlet?

Subject: Re: [boost] Best Practices for Surviving the Boost Test Gauntlet?
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-08-09 22:25:38

On Wed, Aug 9, 2017 at 3:11 PM, Raffi Enficiaud via Boost
<boost_at_[hidden]> wrote:
> 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-win2012R2-32on64-boost-bin-v2-libs-beast-test-beast-core-buffer_cat-test-msvc-12-0-dbg-lnk-sttc-thrd-mlt.html

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.targets.requirements

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/017510215122c013579f6c74631468a92e7a4d6d>

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