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