Re: [jamboost] Regression test log request

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 
and
>> the toolset name?
>>
>> By "start" I mean before any other messages related to that test 
appear.
>
>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 
their
>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 
have
>multiple dependent test targets. When we start to build that target, 
which
>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 
now.)

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 
needs
>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 
do
>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.

--Beman