[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
author.
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
- Re: new DejaGnu team member, (continued)
- RE: new DejaGnu team member, Dan Kegel, 2003/07/24
- RE: new DejaGnu team member, Dan Kegel, 2003/07/25
- Re: new DejaGnu team member, James Dein, 2003/07/25
- Re: new DejaGnu team member, Dan Kegel, 2003/07/25
- Re: new DejaGnu team member, James Dein, 2003/07/25
- Re: new DejaGnu team member, Dan Kegel, 2003/07/25
- Re: new DejaGnu team member,
James Dein <=
- Re: new DejaGnu team member, Dan Kegel, 2003/07/25
- Re: new DejaGnu team member, James Dein, 2003/07/25
- Re: new DejaGnu team member, Dan Kegel, 2003/07/25
- Re: new DejaGnu team member, James Dein, 2003/07/25
- Re: new DejaGnu team member, Dan Kegel, 2003/07/25
- Re: new DejaGnu team member, James Dein, 2003/07/25
- Re: new DejaGnu team member, Rob Savoye, 2003/07/25
- Re: new DejaGnu team member, Daniel Jacobowitz, 2003/07/25