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

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

I believe this code is correct:

#ifndef BOOST_NO_CXX11_HDR_INITIALIZER_LIST static std::map 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 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_6...

or that: http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP...

?

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

Maybe because of "-Werror=unused-parameter" ? or maybe this one is hiding something else?

...

http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...

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