From: David Abrahams (dave_at_[hidden])
Date: 2002-08-17 13:24:28
From: "Beman Dawes" <bdawes_at_[hidden]>
> 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
> fail to compile.
> 4) Again, run bjam "-sTOOLS=metrowerks" config_test
> Note that the compile fails, but then everything else is skipped,
> in the residue in
> boost-root/config_test.test/metrowerks/debug/runtime-link-dynamic making
> appear as if the test still passes.
> At the very least, the residue .success file should have been deleted and
> .failure file created.
Beman, c'mon, this isn't fair! When we talked on the phone you said this
wasn't the problem you were seeing. We specifically discussed the .success
and .failure files, and IIRC you understood why they were still around. You
said the problem was that instead of skipping targets dependent on the
broken library, they were building anyway using an older version of the
.lib that was still hanging around. How can I expect to support your
testing requirements if you keep changing the story?
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com
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