Re: new DejaGnu team member

From:

Dan Kegel

Subject:

Re: new DejaGnu team member

Date:

Fri, 25 Jul 2003 10:20:16 -0700

User-agent:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617

James Dein wrote:

The idea is to execute dg-style tests (where dg is a simple
high-level driver used by many of the gcc tests) in parallel,
and leave other styles of test alone. (I think gcc is moving
more of the tests towards dg in order to make it easier to support
that other regression testing framework.)
This lets you easily pipeline compilation and execution,
since dg-style tests do nothing but run simple standalone programs
in batch mode on the target.

It's not quite so simple as that, because when programs are downloaded
to target boards, the harness has to wait for them to finish so that it
can glean the exit status, which sometimes means grepping the status
info from the program's output.

Sure, I know that. Doesn't complicate my idea at all, since I was
already planning on that.

I should probably mention at this point that I am currently working on
enhancements to `dg' to handle multiple source files per test. We will
be writing tests for this new feature and testing them -- and the DG
enhancements -- regularly, on native. I will, of course, perform some
non-native runs of the tests to make sure I haven't broken the `remote'
system. Anyway, let's make sure our improvements dovetail rather than
clash. The main trick (with my work) is to make sure the source files
get downloaded to the "remote host" before the compiler gets invoked.
Executing executables does not become harder (or easier :-). Handling
dg-warning and friends requires sorting messages by source file.
There's no rocket science involved, I think.

Can you give an example of when you'd need to use this new feature?
Also, you may want to coordinate with the guy who's implementing
dg support in QMTest.
- Dan