On 11/12/2016 5:55 AM, Peter Dimov wrote:
Edward Diener wrote:
How do you get Travis CI to continue the build when a single invocation with just one of the toolsets fails ? Even though clang failed I still want it to try gcc.
There is no gcc on Travis's OS X images, just Apple clang.
I am missing something with Travis CI. The iostreams .travis.yml says to run the tests for linux and osx, to run using gcc and clang, and to run just clang on osx. The test then runs on osx with clang, and then none of the other combinations are run at all. That seems pretty poor to me. Surely there must be an easy way on Travis CI to not only control the order of the tests to run but to tell Travis CI to finish running the tests when one of them fails.
To me its guesswork since I do not know what version of clang is being used or what version of libc++ is being used...
The same error is present here:
http://www.boost.org/development/tests/develop/developer/Sandia-darwin-iostr...
so you can see the versions here:
http://www.boost.org/development/tests/develop/developer/output/Sandia-darwi...
OK, I see it. I don't have a Mac and I don't know what version of clang "clang-darwin-4-2-1" refers to, not that it would do any good if I knew <g>.
This however is not enough to determine whether libc++ supplies a primary definition of codecvt on other configurations. If I had to guess I would test for defined(_LIBCPP_VERSION) && defined(__APPLE__).
I can do that. Maybe add a test that just outputs the clang version and libcpp version and then use that specifically after it cycles in the regression tests to define BOOST_IOSTREAMS_NO_PRIMARY_CODECVT_DEFINITION.
The root problem, of course, is that the standard does not mandate a primary definition, so the code is simply broken. It should define specializations of codecvt<> instead of trying to supply a primary definition when there isn't one. But there may have been historical reasons to write it that way.