[libgo] Improve Solaris 2/SPARC support

[Mike Stump]

On Mar 31, 2011, at 9:05 AM, Ian Lance Taylor wrote:
> Rainer Orth <ro@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 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 suspect, leaving all the bugs and features in place, and then just incrementally test and expand coverage.  The advantage of doing the whole thing (dejagnu, testsuite/lib/*) all at once would be to increase the odds that there would be enough features implemented to actually support migrating everything to the new system.  The problem is, unless someone has a cool 3-9 man months to donate, half solutions just forever lag behind, and then we wind up with multiple infrastructures, all alike, but all different.  This later state, is, I'd claim, not a place 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 basket, so that most people don't ever have to write any tcl code or driver code or worry about what a timeout is, or how you get a file from point a to point b.  Most of the time, you just add the one testcase your interested in, and your done.

Now, another strategy would be to have a driver .exp file leap off into python directly and then just call pass for each line with PASS:, fail for each FAIL: and so on.  The advantage, one could start converting a single small area, the only down side, we'd probably wind up with quite a few of the testsuites unconverted, with twice the code, and random missing features for a long time.  :-(

I don't mind moving away from dejagnu, but, unless someone wants to donate a lot of time and code...