|
From: | James Dein |
Subject: | Re: new DejaGnu team member |
Date: | Fri, 25 Jul 2003 14:16:07 -0700 |
On Friday, July 25, 2003, at 10:20 AM, Dan Kegel wrote:
James Dein wrote: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.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.Sure, I know that. Doesn't complicate my idea at all, since I was already planning on that.
Just checking! :-)
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?
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.
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.
- Dan
Jim Dein
[Prev in Thread] | Current Thread | [Next in Thread] |