Anybody an idea what is the reason for the "new" white cells (Intel-win32, cw, vc*)? I can find nothing about these tests in bjam.log but a single line in the list at the beginning boost-test(COMPILE) "python/select_arg_to_python_test" : "libs\python\test\select_arg_to_python_test.cpp" ...so it very much looks like they are not compiled at all! Stefan
Stefan Slapeta <stefan@slapeta.com> writes:
Anybody an idea what is the reason for the "new" white cells (Intel-win32, cw, vc*)?
I can find nothing about these tests in bjam.log but a single line in the list at the beginning
boost-test(COMPILE) "python/select_arg_to_python_test" : "libs\python\test\select_arg_to_python_test.cpp"
...so it very much looks like they are not compiled at all!
Maybe. I just changed the subject line because white cells usually indicate a failure in the test script to properly give feedback about problems. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Maybe. I just changed the subject line because white cells usually indicate a failure in the test script to properly give feedback about problems.
I see two problems: First, IMO white is the wrong color for that, it's just too 'innocent'. Second, it should be marked somehow in the summary if there are white cells for a certain compiler. Otherwise, there is a potential danger that these problems might remain undetected. Stefan
Stefan Slapeta writes:
David Abrahams wrote:
Maybe. I just changed the subject line because white cells usually indicate a failure in the test script to properly give feedback about problems.
I see two problems: First, IMO white is the wrong color for that, it's just too 'innocent'.
Well, by themselves white cells don't indicate any problems besides that fact that for some reason the particular test results are missing from the corresponding XML file. In most cases this is totally innocent. The particular problem with Python is that due to uncommon format of its bjam output the helper program that converts it to XML ("process_jam_log") is not intellegent enough to match some failures' diagnostics with the corresponding test cases. Thus, it doesn't produce the corresponding test case entries in the XML, and the reporting tools have no choice but assume that the tests simply haven't been run. IOW, it's "process_jam_log" that needs to be fixed, not the reports' color scheme.
Second, it should be marked somehow in the summary if there are white cells for a certain compiler. Otherwise, there is a potential danger that these problems might remain undetected.
Due to the merged nature of the reports, it's a normal situation to have a few white cells on the library page. In fact, they appear every time a test case is added/removed; they go away when all runners upload the updated results reflecting the change. Propagating these to the summary would simply render it useless. The only valid use case for the propagation is when no test results at all have been found for a particular library/toolset combination, and that's what is currently being done. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (3)
-
Aleksey Gurtovoy -
David Abrahams -
Stefan Slapeta