#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 tdammers): First of all, thanks a lot for the effort, it is very much appreciated. Then, to summarize (correct me if I'm wrong): - The original problem to be solved here is that the testsuite driver (written in Python) shells out to a custom timeout program ({{{timeout.hs}}}); so the idea was to rewrite the whole timeout functionality in Python - Vanilla Python and its libraries (particularly {{{subprocess}}}) are inadequate on Windows, because the process model is different, which makes certain things that we rely on nontrivial (specifically, reliably killing entire process trees). This is why {{{timeout.hs}}} exists in the first place, and why the proposed patch introduces {{{winbindings.py}}}. - The patch does not improve testsuite performance; the goal is to improve maintainability. This raises to the following issues: 1. Between {{{winbindings.py}}} and {{{timeout.hs}}}, I don't see a significant reduction in overall complexity. We remove Windows-specific Haskell code, and replace it with Windows-specific Python code; both are a maintenance liability. 2. {{{timeout.hs}}} works; {{{winbindings.py}}} and the rewritten test driver parts are mostly untested as of yet. There is a nonzero change of this patch introducing new, possibly subtle, bugs. 3. GHC developers are more likely to want to work on complicated Haskell code than complicated Python code, and be competent at it. So Python code in this context has a higher barrier to participation, and a smaller contributor pool to draw from. 4. Managing Python versions, especially on Windows, is a nontrivial effort. The less we rely on it, the better. 5. Given 3. and 4., and also for other reasons, we would prefer moving (parts of) the test driver from Python to Haskell, not the other way around. Ideally, we would want to see the test driver rewritten in Haskell entirely. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15363#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler