Boost logo

Boost :

Subject: Re: [boost] Visual Studio 2015 Update 3 has removedstd::unary_functionand std::binary_function
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-11-12 11:49:47


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-iostreams-clang-darwin-4-2-1-code_converter_test-variants_.html
>
>
> so you can see the versions here:
>
> http://www.boost.org/development/tests/develop/developer/output/Sandia-darwin-boost-bin-v2-libs-config-test-config_info-test-clang-darwin-4-2-1-debug.html

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk