Hey,

I can only address a small subset of your comments as I don't usually
develop on Windows and hence lack any significant Windows experience...

Thanks. Honestly, I'm no fan of Windows either. Not sure how I got into this mess :) 

> 2. Since the msys2 setup instructions are so simple and linear, perhaps it
> would be even better to put them in a shellscript and check that in? Then
> the wikipage would turn into a one-liner.

Fwiw, I recently tried msys2, but after wasting several hours I simply
couldn't get it to work in a way where I could ssh (tried Freesshd and
Winsshd) into an MSYS2 environemnt.

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.

Anyway, this does not seem to be relevant to the build environment discussion...
 
from now on the graphical Windows console/deskopt isn't required anymore
(which was my primary goal). Everything else can be done headless/remote
via ssh:

 - `wget` ghc-7.6.3 windows bindist and unpack to /opt/ghc-7.6.3
 - prepend /opt/ghc-7.6.3/bin/ and /opt/ghc-7.6.3/mingw/bin/ to user's
   PATH via ~/.bash_profile or similiar
 - follow similiar steps to grab cabal and install alex/happy like for
   MSYS2; you need to pass `--configure-option=--build=x86_64-w64-mingw32`
   to cabal, though.
 - apt-cyg install automake git
 - clone and build ghc as if it was MSYS2

Fair enough.

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?
 
> 3. Why is ghc-tarballs a git repository? That does not seem very wise.
[...]
> Could we have a stable folder under haskell.org/ to put the files in, to
> make sure that they never go away, and just wget/curl them from there?

http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887

Hmm, that was a while ago. Whom should I contact to get the files deployed under haskell.org?

> 11. A build with the host gcc failed. I think the cause is that it is too
> new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The build of
> the currently checked in GMP (libraries/integer-gmp) fails because a
> utility used in the build process segfaults. I tried upgrading gmp from
> 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but the ghc-specific patch
> used for 5.0.3 no longer applies (is it still necessary?). Oh brother. One
> of the advantages of tracking msys2's gcc would be that we would notice
> such breakage earlier. Shall I open an issue?

The patched in-tree GMP lib isn't necessary anymore with the rewritten
integer-gmp2 package (which was one of the motivations to do the rewrite
in the first place).

Cool! Why is the old library still in the tree then? Can it be deleted?
 
> Might be a good idea to put in a guard in the configure script to warn
> if a cygwin gcc is detected (or add explicit support for
> it). Actually, looks like there's already a related issue open,
> although I'm not quite sure what the scope is there (#8842
> <https://ghc.haskell.org/trac/ghc/ticket/8842>, thanks Thomas).

It'd be great if one couldn't only use Cygwin as a `build`-environment,
but also as the `host`-environment you compile for.

You mean, being able to build binaries which use cygwin1.dll / msys-2.0.dll? Not sure there's much benefit to that...
 
> 14. The test runner assumes native Windows Python, but it's only a few
> small changes away from working fine on the python2 provided by msys2,
> which would cut another external build dependency. Could someone review and
> merge my patches (#9604 <https://ghc.haskell.org/trac/ghc/ticket/9604>,
> #9626 <https://ghc.haskell.org/trac/ghc/ticket/9626>)? Thanks.

Fwiw, the test-runner seems to work fine with the Cygwin-provided Python
interpreter.

Hmm, interesting...

--
Gintautas Miliauskas