<div class="gmail_quote">On Tue, Mar 29, 2011 at 12:54 PM, Frank Murphy <span dir="ltr">&lt;<a href="mailto:anirishduck@gmail.com">anirishduck@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I&#39;ve been looking around and trying to develop a plan for parallelizing builds<br>
in cabal-install.</blockquote><div><br></div><div>Something I&#39;d love to see, for sure. But the devil&#39;s in the details; see below.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- Parallelize executeInstallPlan. When given a target load average as a flag it<br>
 will determine whether it should spawn a worker (if below the target load<br>
 average) or wait.</blockquote><div><br></div><div>Load average is a very very bad method to use, because it&#39;s very slow to respond to changes in real load on Unix, and it doesn&#39;t exist at all on Windows. Do like &quot;make&quot; instead and just accept a &quot;-j&quot; parameter for the maximum number of jobs to run simultaneously.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">- Rewrite install.*Package and their callees to use the CHP (Communicating<br>
 Haskell Process) monad where possible. Use channels to communicate build<br>
 status back to the main thread.<br></blockquote><div><br></div><div>Why not just use MVar or Chan?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

- It might be necessary to parse the output of external builds in some way so<br>
 that meaningful status can be communicated back to the user.</blockquote><div><br></div><div>Yuck, no. Too fragile. Just check the exit status of a process.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- Add a default parallel build log path template. Allow the user to specify one<br>
 on the command line to override the default. All output of parallel package<br>
 builds will be logged in the background silently instead of displayed to the<br>
 user.<br>
- On single-threaded (sequential) builds, revert to the old output style. On<br>
 multi-threaded builds, display the current status of all running builds, load<br>
 averages and nothing else.</blockquote><div><br></div><div>No to both of these, too. It&#39;s desirable that build outputs shouldn&#39;t scribble on each other via excessive interleaving, but telling people to go read a log file because a build failed is going to give them a very bad experience. For instance, that would defeat the usual way that users of Emacs and other IDEs jump to the first error.</div>
</div>