By the way, I've had various hard-to-pin-down problems with changing capabilities at runtime myself.
Is it possible in this case to just disable the use of that feature for
#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:35 rrnewton]: the initial release? That is, you would have to use +RTS -N to get real speedup. But, hey, it's kind of an advanced compilation feature anyway. In this scenario we could get a lot of testing experience with parallel builds without setNumCapabilities and then combine them when there is higher confidence.
I don't mind going that route if the issue doesn't get sorted out soon. A subsequent point release of GHC could reinstate the feature (automatically setting the number of capabilities for the user), then. But I think I could fix it on time. ---- Replying to [comment:34 simonmar]:
The changes to handle loops look OK to me, but I would test it on a GHC build to be sure. You want to build the whole of ghc/compiler with --make -O2; the build system doesn't do this so you have to make a command line by hand.
At first I couldn't even get GHC to compile itself via `--make -O2` without `-j` (see #8184). Since that's been fixed I was able to build GHC via `--make -O2 -j` after a minor tweak in the code, so the loop handling should be solid now. On to the `setNumCapabilities` issue... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/910#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler