<div dir="ltr">Hey,<br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can only address a small subset of your comments as I don't usually<br>
develop on Windows and hence lack any significant Windows experience...<br></blockquote><div><br></div><div>Thanks. Honestly, I'm no fan of Windows either. Not sure how I got into this mess :) </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 2. Since the msys2 setup instructions are so simple and linear, perhaps it<br>
> would be even better to put them in a shellscript and check that in? Then<br>
> the wikipage would turn into a one-liner.<br>
<br>
</span>Fwiw, I recently tried msys2, but after wasting several hours I simply<br>
couldn't get it to work in a way where I could ssh (tried Freesshd and<br>
Winsshd) into an MSYS2 environemnt.<br></blockquote><div><br></div><div>Actually, that seems to work fine over here. I just needed to install the 'openssh' package using pacman (I think it may have been installed by default), then create a user 'sshd' in /etc/passwd (for privilege separation) and create ssh host keys (ssh-keygen -A). Then "sshd" started a server that I was able to connect to successfully.</div><div><br></div><div>Anyway, this does not seem to be relevant to the build environment discussion...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
from now on the graphical Windows console/deskopt isn't required anymore<br>
(which was my primary goal). Everything else can be done headless/remote<br>
via ssh:<br>
<br>
 - `wget` ghc-7.6.3 windows bindist and unpack to /opt/ghc-7.6.3<br>
 - prepend /opt/ghc-7.6.3/bin/ and /opt/ghc-7.6.3/mingw/bin/ to user's<br>
   PATH via ~/.bash_profile or similiar<br>
 - follow similiar steps to grab cabal and install alex/happy like for<br>
   MSYS2; you need to pass `--configure-option=--build=x86_64-w64-mingw32`<br>
   to cabal, though.<br>
 - apt-cyg install automake git<br>
 - clone and build ghc as if it was MSYS2<br></blockquote><div><br></div><div>Fair enough.</div><div><br></div><div>I prefer msys2 as it seems to be a more minimalistic and simpler environment that Cygwin (and installation seems easier too). Are there other advantages to cygwin?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 3. Why is ghc-tarballs a git repository? That does not seem very wise.<br>
</span>[...]<br>
<span class="">> Could we have a stable folder under <a href="http://haskell.org/" target="_blank">haskell.org/</a> to put the files in, to<br>
> make sure that they never go away, and just wget/curl them from there?<br>
<br>
</span><a href="http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887" target="_blank">http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887</a><span class=""><br></span></blockquote><div><br></div><div>Hmm, that was a while ago. Whom should I contact to get the files deployed under <a href="http://haskell.org">haskell.org</a>?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 11. A build with the host gcc failed. I think the cause is that it is too<br>
> new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The build of<br>
> the currently checked in GMP (libraries/integer-gmp) fails because a<br>
> utility used in the build process segfaults. I tried upgrading gmp from<br>
> 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but the ghc-specific patch<br>
> used for 5.0.3 no longer applies (is it still necessary?). Oh brother. One<br>
> of the advantages of tracking msys2's gcc would be that we would notice<br>
> such breakage earlier. Shall I open an issue?<br>
<br>
</span>The patched in-tree GMP lib isn't necessary anymore with the rewritten<br>
integer-gmp2 package (which was one of the motivations to do the rewrite<br>
in the first place).<br></blockquote><div><br></div><div>Cool! Why is the old library still in the tree then? Can it be deleted?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Might be a good idea to put in a guard in the configure script to warn<br>
> if a cygwin gcc is detected (or add explicit support for<br>
> it). Actually, looks like there's already a related issue open,<br>
> although I'm not quite sure what the scope is there (#8842<br>
</span>> <<a href="https://ghc.haskell.org/trac/ghc/ticket/8842" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/8842</a>>, thanks Thomas).<br>
<br>
It'd be great if one couldn't only use Cygwin as a `build`-environment,<br>
but also as the `host`-environment you compile for.<br></blockquote><div><br></div><div>You mean, being able to build binaries which use cygwin1.dll / msys-2.0.dll? Not sure there's much benefit to that...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 14. The test runner assumes native Windows Python, but it's only a few<br>
> small changes away from working fine on the python2 provided by msys2,<br>
> which would cut another external build dependency. Could someone review and<br>
</span>> merge my patches (#9604 <<a href="https://ghc.haskell.org/trac/ghc/ticket/9604" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/9604</a>>,<br>
> #9626 <<a href="https://ghc.haskell.org/trac/ghc/ticket/9626" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/9626</a>>)? Thanks.<br>
<br>
Fwiw, the test-runner seems to work fine with the Cygwin-provided Python<br>
interpreter.<br>
</blockquote></div><br>Hmm, interesting...<br clear="all"><div><br></div>-- <br>Gintautas Miliauskas
</div></div>