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: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: Jason Merrill <jason at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 31 May 2002 00:27:33 -0700
- Subject: Re: QMTest and the G++ testsuite
> Minor point: It would help if there's a provision for slightly
> more complex interpreter arrangements, at least "interpreter
> program arg1 arg2" could be "interpreter iarg1 iarg2 ... program
> arg1 arg2". Maybe it's already there?
Thanks for thinking about this more.
In light of earlier comments about statefulness, what we want to do is
have the interpreter be an arbitrary piece of Python -- one incarnation
of that is to run an external program as you suggest; another is some
more complex machination where you keep track of whatever state you
If we can get happy about QMTest in native environments, we'll move on
to cross environments.
> Is there a document somewhere that describes the preference for
There are things that make Python a particularly good choice, in my
opinion, but that's not the real reason it's in use. The real reason
is that QMTest was developed under a government contract, and that
contract required the use of Python.
A rational reconstruction goes something like this:
- You want a scripting language because you want it to be easy for
people to write extensions, and you want to be portable.
- Nobody likes Tcl anymore. :-)
- Perl would have been a fine choice too, but (personally) I like
Python better. (Let's not start a religious war on this issue;
it's just a personal preference.)
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com