#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