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
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
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk