Rainer Orth <r...@cebitec.uni-bielefeld.de> writes: > Ian Lance Taylor <i...@google.com> writes: > >> 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. > > Do you have a decent alternative? I've no idea what happened to QMTest > which CodeSourcery tried for the C++ testsuite. > > handwritten shell-scripts like gotest which lack all the basic features > of dg (timeouts, a proper record of which tests ran and their status, ...) > certainly don't cut it for me. So far the libgo testsuite lacks all of > this, causing trouble without end (at least for me). > > I'm certainly not enamored with Tcl, Expect and DejaGnu, but so far they > do a decent job. Having each library run its testsuite as it pleases > with different output and different ways of dealing with XFAILs, > target-dependent options and stuff, is completely unmaintainable IMO.
I don't have a decent alternative. I did just commit code to track test results in a DejaGNU-like fashion, and I will add test timeouts shortly. Still, I think we need to move forward, and the way to move forward is not to move backward. A testsuite needs a little infrastructure, but it doesn't need very much. What is holding us back is not the infrastructure; it's the knowledge currently baked into DejaGNU about how to build programs for target boards and run them there. For native testing we can cobble things together easily enough. Ian
