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

Subject: Re: [boost] [teeks99][test] Test failures on MSVC 8-11
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-11-22 05:20:44

Le 22/11/15 04:17, Andrey Semashev a écrit :
> 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 was referring to a more serious problem that is hidden by this 
warning. But again, if I need to ask the logs at every commits, this is 
not really helping me saving time as a developer.

BTW, is there any policy about warnings?

>
>> 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.

Yes, and I thank you again for your active implication in the quality of 
boost.test and your relevant feedbacks.

And I do not look at the regression dashboard every hours, hoping that 
some new runners have cycled. If the result is not there the next day 
basically, it is naturally/involuntary discarded.

>
>>> 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.

Now you pin pointed the error and the notion I was missing in this init 
list, I will be able to fix the error. Again, thank you, and sorry.

>
>> 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.

I believe this is: if I were able to have a status on our develop branch 
without annoying anyone else, that would definitely help you. If the 
runners were cycling more often, if I had the history, I would be able 
to track down the regressions much more effectively.

For being able to lower the noise/coupling with other libraries, I had 
to deploy a full CI solution with another branching scheme. This is 
supposed to be handled by the regression tools and obviously doing all 
that CI duplication takes a precious time, a time that is taken from the 
development/improvement of boost.test.

So next I will just add gcc 4.4 C++0x to my CI to catch those error 
before they affect you.

Raffi