From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-07-10 20:48:25
At 06:57 PM 7/10/2002, David Abrahams wrote:
>> Is there any chance of getting the current regression test to write a
>> message to cout at the start of each test giving the name of the test
>> the toolset name?
>> By "start" I mean before any other messages related to that test
>We have a generalized DAG describing target dependencies. You want a
>message to appear when the first target on which some test target is
>dependent starts to build. Jam doesn't work that way. The make process
>proceeds by recursive descent through the build dependency tree, starting
>at the target you requested to build. It proceeds from dependents to
>dependencies. There's no provision for looking back up at all the
>dependents of a target. In fact, a target (such as a library) may well
>multiple dependent test targets. When we start to build that target,
>test are we starting?
The effect we want is that there is "library-build" test, and that would be
the one we report as failing. (If it fails, there is no point in even
reporting the tests dependent on that library, but let's ignore that for
How about invoking Jam multiple times?
invoke jam to build library X
add the results to the status table
repeat for libraries Y, Z, ...
invoke jam to run tests
add those results to the status table
Note that <lib> dependencies have to be removed from the current
boost-root/status/Jamfile, since we just want the tests to fail if a
library isn't present. We don't want to try to build the library while
processing the status/Jamfile.
This seems pretty simple, or am I missing something?
I'll have to look at the normal library build output to see if it is
possible to tell if it succeeded or not, but if necessary I can hand write
some C++ code that looks for the lib files.
>It's clear to me that we need to look at what features a build system
>in order to support testing, and we'll need to modify Jam accordingly.
>Unfortunately, I don't have the time to do that right now, much less to
>it alone. Because it's clear that some momentum is building behind the
>testing system, I'd be willing to help someone else think it through. If
>it's not too complicated, we can try to implement it (though this is
>probably the hairiest part of the Jam source).
Hopefully, the scheme above won't require a lot of changes.
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