[GHC] #15363: Do some cleaning up of the testsuite driver

[GHC]

#15363: Do some cleaning up of the testsuite driver
-------------------------------------+-------------------------------------
        Reporter:  lantti            |                Owner:  lantti
            Type:  task              |               Status:  patch
        Priority:  low               |            Milestone:  8.8.1
       Component:  Test Suite        |              Version:  8.4.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D5107
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by lantti):

 I agree with this summary. To add some more (possibly superfluous)
 details, the original problem is not only Windows specific. In order to
 maintain a consistent interface the current POSIX code path also shells
 out an external process (a separate python interpreter) to handle the
 timeout and interrupting functionality even when {{{subprocess}}}
 functionality would be adequate on POSIX.

 To issue 1.: I have nothing to add.

 To issue 2.: I'd like to add that even {{{timeout.hs}}} itself is not
 fully functional at the moment, failing to handle interrupts signals,
 although {{{winbindings.py}}} doesn't do any better job either.
 Interrupting the test run on Windows works only because {{{mintty}}}
 simply kills our whole process tree without consulting our code at all,
 resulting in different but still effective end to the test run (compared
 to POSIX). The results for the tests already run won't get displayed in
 that case but fortunately this functionality doesn't strike me as
 essential.

 To issues 3,4,5: If this is the direction we should be going I'll happily
 align my efforts with it instead. I was under the impression that
 currently hs->py was the preferred way as according to the git logs
 (e5063a042c9a1701ea7273da7bacb530d5c077d3) GHC used to have a testsuite
 language and appropriate interpreter implemented all in Haskell. The
 stated motivation to move away from the Haskell code was maintainability
 but presumably we have a lot better Haskell libraries now than back then
 and the maintainability would perhaps not become such an issue anymore.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15363#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler