[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new DejaGnu team member

From: James Dein
Subject: Re: new DejaGnu team member
Date: Fri, 25 Jul 2003 14:55:21 -0700

On Friday, July 25, 2003, at 2:22 PM, Dan Kegel wrote:

James Dein wrote:
Can you give an example of when you'd need to use this new feature?
We need it immediately (literally!), which is why I'm working on it now. I have written an internal design doc that has been reviewed and approved. However, a proposal to this list would have to be more explicit than what I put in the doc.

How about a hint? :-)

Oh, OK. :-)

In the new scheme, dg-do <what> is joined by dg-do <what> <style> <slave-file-list> where <style> is one of "onestep", "multi", and "serial", and the slaves are files that contain dg-do dummy. The non-dg-dummy files are _master_ test files.

  onestep -- src files are compiled in one step, output is a single file
  multi -- same, but each file produces a single output file
  serial -- same, but files are compiled individually

Rather than being completely explicit at this time, let me just say the some sort of "environment" may pertain while the compiles are going on, and the results, even in the 3rd case, may depend on all the input files at once. Or not. :-)

Note that only one dg-do is recognized per file, just like now.

Routines such as proc default_target_compile have to be gently modified and/or provided with glue front ends so that they will handle lists of source files.
It should be possible to run today's tests absolutely unchanged.

Also, you may want to coordinate with the guy who's implementing
dg support in QMTest.
QMTest?? What's that? And, who's that? Naturally, I want to coordinate whenever possible. My work should be backward compatible with today's dg. That is a principal design goal.

That's also one of QMTest's goals (where dg != dejagnu, but rather the
little dg driver built on top of dejagnu). QMTest is a Python-based GUI-mostly dejagnu replacement. See testsuite/README.QMTEST in the gcc source tree.
Also, search the gcc mailing list archives for posts by the QMTest

Of course: dg (pron diggy :-) is the machinery in lib/dg.exp, and DG = DejaGnu. I just read README.QMTEST, and I think they have overlooked certain important facts, but would rather not discuss that on this list, at least not now. Anyway, they have nothing to fear wrt current dg-style tests, and it should probably be clear to them how to incorporate my changes when/if they care to do so.

I'm not endorsing QMTest, just noting that they are
supporting dg in a non-dejagnu environment, and
you want to avoid pissing them off because they're
doing something that is a Good Thing, namely rewriting
a lot of the non-dg tests into dg form.
- Dan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]