<div dir="ltr">hey all, I just exported the igloo builder code from darcs to git, and put it here <a href="https://github.com/cartazio/ghc-builder">https://github.com/cartazio/ghc-builder</a><div>would this be something worth adding to <a href="http://github.com/haskell">github.com/haskell</a>  ? (i can easily add it if other folks it should be surfaced more visibly)</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 11:04 AM, Páli Gábor János <span dir="ltr"><<a href="mailto:pali.gabor@gmail.com" target="_blank">pali.gabor@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2014-04-01 14:03 GMT+02:00 Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>>:<br>


<div class="">> Indeed, there is no reason not to use Ian et al's Builder stuff.  It's one of the<br>
> options.  But it depends on a critical evaluation of what the advantages and<br>
> disadvantages of different approaches are<br>
<br>
</div>I found Ian's buildbot an appealing alternative as it does a full<br>
build, including testing, and uploads the resulting binaries to a<br>
common place where anybody can access them (but it can be configured<br>
to do almost anything).  The builders may be configured individually<br>
from a single (Haskell-language) configuration file and they are run<br>
on various volunteer-supplied systems so it is also distributed.<br>
<br>
I use this to keep track of the status of the FreeBSD builds to make<br>
my work easier on building the releases and maintaining the associated<br>
ports in the FreeBSD Ports Collection, while offering regular<br>
developer snapshots for the users.  This approach also allows me to<br>
control and maintain the builder environment too as it may require<br>
minor or major changes and fixes over time that I can do myself as a<br>
FreeBSD developer.  In the past, there were cases where the build was<br>
failing due to bugs in the kernel or the userland, so this is not<br>
purely about GHC itself (unfortunately).<br>
<br>
In my humble opinon, there are merits for the Travis-based Continuous<br>
Integration, so as for the daily snapshot building on each supported<br>
platform.  I do not care if it is not Haskell-based or it is hosted at<br>
a central place with individual Virtual Machines for each platform --<br>
until I can keep doing what I have been doing for 4 years now.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>