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