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