On 1 September 2011 08:44, Evan Laforge <qdun...@gmail.com> wrote: >> Yes, the plan was to eventually have a parallel --make mode. > > If that's the goal, wouldn't it be easier to start many ghcs?
Yes. With Scion I'm in the process of moving away from using GHC's compilation manager (i.e., --make) towards a multi-process setup. This has a number of advantages: - Less memory usage. Loading lots of modules (e.g., GHC itself) can take up to 1G of memory. There are also a number of caches that can only be flushed by restarting the session. - Sidestep a few bugs in the compilation manager, such as non-flushable instance caches which lead to spurious instance overlaps. (Sorry, can't find the corresponding ticket, right now.) - An external compilation manager (e.g., Shake) can also handle preprocessing of other extensions, such as .y, .chs, etc. - Support for different static flags (e.g., -prof). Static flags should eventually be removed from GHC, but it's low-priority and difficult to do. - Uniform handling of compilation with multiple versions of GHC. - Parallel building, as you mentioned. There may be more. It also comes with disadvantages, such as the need to serialise more data, but I think it's worth it. This is the main reason why I stopped working on a thread-safe GHC. Personally, I believe the GHC API should just include a simple API for compiling a single module and return some binary value (i.e., don't automatically write things to a file). Everything else, including GHCi, should be separate. But that's a different matter... -- Push the envelope. Watch it bend. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
