This is the mail archive of the
mailing list for the GCC project.
Re: QMTest and the G++ testsuite
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 20 May 2002 09:18:54 -0700
- Subject: Re: QMTest and the G++ testsuite
--On Monday, May 20, 2002 03:57:57 PM +0100 Jason Merrill
> My main concern is support for cross testing; there's a lot of code in the
> DejaGNU suite for dealing with different build/host/target combinations.
Thanks for responding!
OK; let's explore this issue further.
At present, you can specify an "interpreter" which is supposed to have
the property that:
interpreter program arg1 arg2 ...
program arg1 arg2
would do if run natively. Are there problems with that interface?
Now, there is the question of writing the interpreters for various
setups; you need the logic to zap the code to the target board, run it,
extract the output, zap it back. The interpreter script is usually
trivial if you have a simulation environment.
I'm happy to write or help write those interpreters, within reason.
(It might even be possible simply to grab the Tcl from DejaGNU and use
it directly.) Do we really need all of rlogin, tip, telnet, kermit,
and xsh? My guess is no; perhaps people using the FSF tree to test
cross compilers to real target boards could comment on which of the
DejaGNU connection methods they really use?
There's also the issue of the stuff in baseboards. Most of that
actually applies to GDB, more than to GCC, and so is not an issue in this
context. But, we can deal with what does arise there.
Let's take it one step at a time.
Maybe we could get to the point where we could approve using QMTest for
native g++ testing first, and then work on to cross-compilation. It
definitely makes sense to have a transition period where both methods
are in use.
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com