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

Subject: Re: [boost] Best Practices for Surviving the Boost Test Gauntlet?
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2017-08-09 22:11:36

Le 09.08.17 à 23:34, Vinnie Falco via Boost a écrit :
> On Wed, Aug 9, 2017 at 2:15 PM, Raffi Enficiaud via Boost
> <boost_at_[hidden]> wrote:
>> Le 08.08.17 à 16:12, Vinnie Falco via Boost a écrit :
>> It seems that you redeveloped a testing framework, and this is causing some
>> of the issues we can read there.
>
> Is there a link to the evidence of this so that I can come up with a fix?

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

Now, I do not know if this is relevant. 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

example in project:
https://github.com/boostorg/test/blob/develop/test/Jamfile.v2#L30

>> I do not know how important is this internal framework to you, but you may
>> go for another test framework and focus on the added value of your library
>> instead.
>
> Changing test frameworks means refactoring all the tests - I'm sure
> you can understand why I might be reluctant to do that right now.

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.
OTOH, if later is never ...

Your call anyway :)

Raffi