More on bjam failure

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-16 09:44:12

Dave Abrahams failed to reproduce the failure I reported yesterday on the 
main list, where bjam seemingly did not recognize that a library compile 
had failed, and so did not report the test as failing.

I can reproduce the failure here at will.

Dave's travelling today, so so I though I'd post to jamboost and see if 
anyone else can figure out what is happening.

You can see the bjam log of step 4 below with -d3 at 
http://www.esva.net/~beman/jam_regr.log

Here is how I reproduce the failure (all in boost-root/status):

1) Run bjam "-sTOOLS=metrowerks" config_test

That should work w/o problems, producing output in 
boost-root/status/bin/config_test.test/metrowerks/debug/runtime-link-dynamic

2) Look that directory, noting the timestamp on files there.

3) Change boost-root/libs/test/src/unit_test_log.cpp in some way so it will 
fail to compile.

4) Again, run bjam "-sTOOLS=metrowerks" config_test

Note that the compile fails, but then everything else is skipped, resulting 
in the residue in 
boost-root/config_test.test/metrowerks/debug/runtime-link-dynamic making it 
appear as if the test still passes.

At the very least, the residue .success file should have been deleted and a 
.failure file created.

5) Delete bin/config_test.test/metrowerks/debug/runtime-link-dynamic

6) Again, run bjam "-sTOOLS=metrowerks" config_test

Notice that the net result of this test after directory deletion is that 
bin/config_test.test/metrowerks/debug/runtime-link-dynamic contains no 
residue files at all. The only file it contains is the .obj

While the post-jam processing program is smart enough report this as a 
failure, it still seems like a serious hole in bjam testing to me. When 
doing testing, knowledge that a test failed (and when, why, etc) is just as 
important as knowing that a test succeeded.

Let me know if more tests are needed.

--Beman