On Sun, 22 Jun 2008, Daniel Jacobowitz wrote: > On Sun, Jun 22, 2008 at 07:13:03PM +0200, Ralf Wildenhues wrote: > > Has anybody ever looked at using threading capabilities of tcl directly? > > Parallel DejaGNU could benefit other packages too. There is a thread > > pools package (tpool.html, linked from <http://wiki.tcl.tk/2770>) but I > > have no idea how functional it is in practice; likely the GCC testsuite > > would need at least a bit of restructuring, too. > > [Insert QMTest plug here] > > I don't know for sure whether the QMTest support in the testsuite is > still good... we use QMTest internally, but not for GCC at the moment. > I'd love to get it working again, at least for native. That can > parallelize tests as fine-grained as you wish, and present consistent logs.
I'm pretty sure it's very bitrotten; it depends on an externally maintained emulation of testsuite logic (qmtest_gcc), and the testsuite has moved on a *long* way since in terms of custom Tcl code to control which tests apply on what systems, with what options (target-supports* etc.). Unless people wish to put in the work to make it operational again for 4.4, I think the code in GCC should be removed (not deprecated, it's too far bitrotten for that). (If people do wish to use this code long term, qmtest_gcc probably needs to be an integrated part of GCC, not a separate package.) A cleanup I'd like to see, regardless of any move to QMTest, is making all testing installed testing (via installing in a temporary directory in the build tree). The testsuite should not need to know how to tell the compiler to find bits of itself in a build tree, only "make install" should need to know how to put such bits together in an install tree so the compiler can find them without special options. (Worse, core DejaGnu itself has hardcoded knowledge about how to locate bits of GCC source and build trees, some of it long obsolete. It's unfortunate that qmtest_gcc has such logic as well, as needed when emulating the DejaGnu logic, but at least QMTest and qmtc don't.) -- Joseph S. Myers [EMAIL PROTECTED]
