From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-07-09 11:09:25
At 09:28 PM 7/8/2002, David Abrahams wrote:
>This is exactly the sort of thing I was afraid would arise. AFAICT
>no simple way to put this in the build system without making core Jam
>The basic problem looks like this. Given a dependency chain:
>when building "e" fails, you want something to happen with the
>.test/.success/.failure files. These are associated with A. However, the
>build system just stops working on "a" the instant any of its
>fails to build.
Ah. That is a nice explanation, and gives me a better understanding of what
As long as a program scanning the output log and the residue left in the
test directory can figure out where in the a->b->c->d->e chain a problem
occurred, I may be able to deal with it.
> In Boost.Build v2, it will be much easier to deal with
>this, because we can traverse the dependency graph generated for A
>ourselves, and attach actions to erase the result files at all the
I've got some ideas about how to make the output from Boost.Build v2
regression tests easier to used. I don't know it is premature, but I'll
mention a few now:
* Having results spread over so many files (.run, .output, .success,
.failure, .test, cout, and cerr ) is a major pain. If these could be
consolidated into a single file, or at least a smaller number of files,
that would make life much easier.
* It would be easier if the residue file name (or names, if they can't be
combined) were always the same. For example, instead of it being
abc.output for test abc, and then xyz.output for test xyz, call it
test.output for all tests.
* Even if the cout/cerr output for a given test can't be combined with the
other output and placed in the appropriate sub-directory, some format
improvements would help a great deal. For example,
* Any output captured from a compiler, linker, test run, or whatever should
be nested inside some easy to identify header and trailer. This is
happening now for some C++ compile failures:
compiler output here
...failed metrowerks-C++-action blah
But in other cases, the ...failed line is missing. Makes parsing very
difficult, sometimes impossible.
* The "blah" in messages like the above is actually something like:
While that may be needed for other purposes, for regression tests what is
often needed is the name of the test which failed, and the name of the
toolset involved. So a separate message may be needed.
* Top level needs identification on lib build failure. In the above
example, some test needed the regex library, and that kicked off the regex
build which then failed. What may be needed here is an explicit test type
"lib-build" to go with "compile", "run", etc. Then lib build failures
would show up on the status table in a very understandable way.
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