Re: new DejaGnu team member

[Dan Kegel]

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