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

Subject: Re: [boost] Best Practices for Surviving the Boost Test Gauntlet?
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-08-09 23:34:24

On 8/8/17 7:12 AM, Vinnie Falco via Boost wrote:
> Beast won the first battle, but it looks like it is losing the war:
> 
> <http://www.boost.org/development/tests/develop/developer/beast.html>
> 
> I've never heard of many of these platforms let alone know how to go
> about fixing the compile, link, and runtime errors. It seems like
> deallocate() is not part of some standard library's allocator_traits?
> Link error on operator delete from Boost.System? A lot of little
> thing.
> 
> Is there a document or resource which explains the various
> peculiarities and idiosyncrasies of these platforms and toolchains
> that I might have a means of fixing them without actually installing
> them locally (which is unlikely)?

I looked at your results, and they don't look half bad for a first attempt.

I can share you the benefit of years of experience dealing with this. 
It's much better now that it used to be.

a) Make sure your code aims for standard C++.

b) Any failures are now due to compilers/libraries failing to meet the 
standard.

c) Now study documentation on config.hpp.  It's very complete, readable 
and not at all difficult to use.  It basically entails tweaking your 
code as suggested by the documentation.  You'll find that a lot of 
problems disappear after a relatively short session as many problems are 
in a header show up in every test.

d) You can tweak your test/jamfile so that it skips tests which are not 
applicable.  For example if your library doesn't have header X you can 
arrange to skip those tests which require header X.  The information is 
in the documentation for config.hpp.  Also the test/bjam file for the 
serialization library does this and you see the syntax there.

e) If you follow the above to the end, you will find that your tests 
will run on all versions of C++ since you've excluded those 
tests/compiler combinations which cannot pass.

f) FWIW I use my own variation of lightweight test.  As long as your 
test returns a 1 (failure) or 0 (success) I don't think it matters which 
test framework you use.

g) When you get all done with the above, you'll have most of the tests 
running on most compilers.  The failures are just that - things that 
can't be made to pass without mucking up your library.  Just note that 
it's the vendors problem and move on.

h) When all this is done, get down on your knees say a prayer of thanks 
to the almighty that your library is header only.

Robert Ramey