Re: [boost] [teeks99][test] Test failures on MSVC 8-11

Subject: Re: [boost] [teeks99][test] Test failures on MSVC 8-11
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-11-21 22:17:08

On 2015-11-21 23:54, Raffi Enficiaud wrote:
> Le 21/11/15 14:35, Andrey Semashev a écrit :
>
> I didn't lie, I fixed the MSVC issues. Also I asked on how to compile
> with gcc4.4~c0x, but I got no answer and I do not know where to look.

I didn't see you asking. You can compile with gcc 4.4 in C++11 mode 
pretty much the same way as you can with newer gcc versions - by adding 
-std=c++0x or -std=gnu++0x to the command line.

>> gcc 4.4 is still failing.
>>
>> http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_64-boost-bin-v2-libs-log-test-attr_attribute_set-test-gcc-4-4~c0x-debug-build-no-threading-multi.html
>>
>>
>
> I believe this code is correct:
>
> #ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST
> static std::map<char,char const*> const char_type{{
>      {'<' , "lt"},
>      {'>' , "gt"},
>      {'&' , "amp"},
>      {'\'', "apos"},
>      {'"' , "quot"}
>      }};
> #else /.../
>
> Maybe I am missing something.

You're using unified initialization syntax, which is indicated by 
BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX. 
BOOST_NO_CXX11_HDR_INITIALIZER_LIST indicates <initializer_list> header 
absence. If you use both, like in the code above, then you should be 
checking both macros.

> What am I supposed to do with this log?
> http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_64-boost-bin-v2-libs-test-test-algorithm-test-test-gcc-4-4~c0x-debug.html
>
>
> or that:
> http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP1-ARM-boost-bin-v2-libs-test-test-algorithm-test-test-qcc-4-4-2_arm-debug-debug-symbols-off.html
>
>
> ?
>
> Why aren't the runners be able to capture the outputs?

Yes, this is a common problem with the current infrastructure. As far as 
I understand the scripts are not always able to pinpoint the source of 
failure and as a result the link points to a random console output.

Testers do have a full log and upon request on this mailing list may be 
able to provide it.

>> as well as mingw testers hosted by Ion:
>>
>> http://www.boost.org/development/tests/develop/developer/output/igaztanaga-gcc-4-9c++14-boost-bin-v2-libs-log-test-attr_attribute_set-test-gcc-mngw-4-9c+-dbg-dbg-symbl-off-thrd-mlt.html
>
> Maybe because of "-Werror=unused-parameter" ? or maybe this one is
> hiding something else?
 >
>> http://www.boost.org/development/tests/develop/developer/output/igaztanaga-gcc-5-1c++14-boost-bin-v2-libs-log-test-attr_function-test-gcc-mngw-5-1c+-dbg-dbg-symbl-off-thrd-mlt.html
>>
>>
> and maybe because of "-Werror=sign-compare" ? or again this is hiding
> something else that was cut off in the report...

Nothing is hidden, the command line is shown in the output and it 
contains -Werror. My point is that these warnings should probably be 
fixed or silenced.

> I believe this is the wrong thing to do for those runners: raising those
> trivial warnings as errors makes them quite useless and this is a waste
> of time and resource for everybody.
>
> Is boost.test compiling for the end users of those platform? I do not
> know. Those runners are telling just nothing.

I've posted links to the concrete build errors, with command lines, 
isn't that enough? If you see your tests are failing and don't see any 
meaningful errors in the output, you could at least ask here instead of 
silently ignoring the failures.

>> Really, I'm very disappointed by Boost.Test quality lately.
>
> What is the point you are trying to make?

I'm saying that I'm seeing lots of failures caused by Boost.Test in my 
tests that were passing before for a long time. First caused by 
inadvertent switch to C++11 only, then the breakage that started this 
thread. This doesn't help my development.

> On my side, I believe the regression workflow and tools **can and
> should** be improved (runners cycling more frequently, outputs properly
> captured, history, no downtime due to some big zip file, better
> ergonomy, more responsive, etc etc).

I'm not happy with regression infrastructure myself, but that's 
irrelevant to the problems I'm pointing out in this thread.