This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: QMTest and the G++ testsuite



> And how about say the GDB testsuite, in which it may be necessary to
> run GDB on one machine, compile one or more source files on another,
> connect to a board and upload the program to it using rcp, NFS, tftp,
> kermit or other board-specific mechanisms, and then issue commands to
> gdb and verify that they had the correct effect on the program?

All of these things can be done.  If you are going to make me replace
*all* DejaGNU testsuites in existence in a single go, before considering
moving to a new tool, that will be too much work.

My goal is to get the process started -- I've offerred to do what it
takes for GCC.  If nobody's interested enough to move on to GDB, well,
that will be that.

You're right to focus on the costs and benefits.  I just think you've
missed some of the benefits. :-)

> little point in switching, since I haven't seen practical advantages
> of using QMTest so far (other than the fact that it's written in
> Python, which I find infinitely more palatable than tcl/expect, which
> is a welcome change for me).

There are a number of other advantages:

1. Support for distribution and parallelism.  If you have ten
   machines with four processors each, you can use all of them.
   Lots of people can benefit from this these days.

2. A more uniform interface than DejaGNU, both internally and
   externally.

   (For example, you can wire things up so that GDB and GCC and G++
   are all tested with a single qmtest command, and the complete
   results are available to you in an organized fashion.  You could
   press one button to test your entire OS, if you wanted.  You can
   do this without understanding how the various pieces need to
   get tested.)

   Note that as a side-effect, it's easier to develop new kinds of
   tests.  Working with DejaGNU is notoriously painful.

3. A GUI.

4. Active development towards new features that will be of use;
   historical storage and display of results, for example.

It's fair to point out that there are migration costs.  However, let
me point out that I have volunteered to mitigate them, by doing
the work involved to set up the GCC tests.

Note that my first request was to *permit* people to do their testing
with QMTest.  That allows us to compare the tools side by side --
without forcing anyone to switch or committing us to switching.

But, it means that people who want to use QMTest can do so without
having to also run the DejaGNU tests.  Isn't that a reasonable place
to start?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]