On Thu, 31 Mar 2011, Mike Stump wrote: > On Mar 31, 2011, at 9:05 AM, Ian Lance Taylor wrote: > > Rainer Orth <r...@cebitec.uni-bielefeld.de> writes: > >> I'm especially suffering from hangs on Solaris 8/x86 and Solaris 8 and > >> 9/SPARC (not yet filed or investigated), which hangs the whole build (PR > >> go/48242). If I get around to it, I'll probably replace gotest by a > >> dg-based testsuite. > > > > Argh, no, I am trying to fight against that as long as possible. We > > should be moving away from DejaGNU, not toward it. > > The way forward is simple. Create a dejagnu replacement in python (or > other suitable language), excise all tcl code in the testcases into
If you want a replacement in python, QMTest already exists. It only has a little built-in support for running some sorts of DejaGnu testcases, but that's a feature, not a bug; relying on bits of DejaGnu such as dg.exp that are too closely involved in the details of compiler testing has caused plenty of problems when we'd like to modify those bits as part of enhancing the GCC testsuite; putting things such as dg test parsing and GCC diagnostic parsing directly in the GCC testsuite code is probably better than relying on the bits of support present in core QMTest (but you can subclass those bits to the extent that they are useful). > driver fragments in the driver area (testsuite/lib), and slowly expand > it out from native only to cross to canadian cross and across test > suites. An ambitious person could convert the whole thing en mass I Note that it's possible to use a DejaGnu board file with another test harness (via a special testsuite that waits for "compile" and "run" commands and wrapper scripts, run by the other test harness, that send those commands). You probably don't get parallelization that way (where it would be possible with a native QMTest host class) but the real issue is not existing board files (which you can use more or less as well as you can use them at present), it's all the Tcl code in the existing testsuites. > we want to be either. By migrating to dejagnu, you at least condense > down to one infrastructure, which is good. We put all our eggs into one Yes. And migrating those testsuites that still use .x files instead of dg.exp to use dg.exp would similarly be good. -- Joseph S. Myers jos...@codesourcery.com
