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?
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
11. A build with the host gcc failed. I think the cause is that it is too 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