"Phil Richards" <news@derived-software.ltd.uk> wrote in message news:20050617123730.1CBD743F7@derisoft.derived-software.demon.co.uk...
Thought I would try and track down the reason for the "Fail" being shown in the HTML regression report generated by compiler_status.
(Is there a better mailing list/forum for reporting problems with these tools?)
The following logic is used to determine whether a test passed or failed:
xml::element_ptr dbp = xml::parse( file, pth.string() ); const xml::element & db( *dbp ); const xml::element & run_element( find_element( db, "run" ) ); pass = !run_element.name.empty() && attribute_value( run_element, "result" ) != "fail";
So, for a test to be shown as "Pass", !run_element.name.empty() must be true - which requires that the XML test result blob contains a "run" element. Tests which are aimed purely at testing expected compile-time fails (e.g., function/function_30) get the following XML generated by process_jam_log:
<test-log library="function" test-name="function_30" test-type="compile" test-program="libs/function/test/function_30.cpp"
target-directory="bin/boost/libs/function/test/function_30.test/gcc/debug" toolset="gcc" show-run-output="false"> <compile result="succeed" timestamp="2005-06-17 10:25:10 UTC"> </compile> </test-log>
So, the test passed, but compiler_status will show a fail due to the lack of a "run" element.
The "pass" assignment should take account of the "test-type". (I can put a patch together, but I might not cover all the cases since I don't know the system too well yet.)
I've recently added better test case coverage for compiler_status.cpp, but still no compile-fail test:-( I'll add a case for compile-fail. Assuming it shows the failure you report above, then I'll take a look at your proposed patch. May be a couple of days before I get to it. Thanks for helping, --Beman