Hello! 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... On 2014-09-27 at 23:04:38 +0200, Gintautas Miliauskas wrote: [...]
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. Then I simply installed Cygwin against the recommendation, and then I finally got a working ssh-able environment with a few steps, which roughly where OTTOMH: - Install cygwin (make sure 'wget' and 'openssh' gets installed), - grab https://github.com/transcode-open/apt-cyg and place into /usr/local/bin/ - "cygrunsrv" in order to install sshd service - allow 'sshd.exe' in Windows-firewall settings 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 Long-story short, if it wasn't for Cygwin, I wouldn't have been able to clean up after some of the Windows breakage I caused recently. It'd be interesting though if there was a way to `ssh` directly (with a sane terminal-emulation) into an MSYS2 environment capable of building GHC.
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
8. A broader question: what general approach to ghc on Windows shall we take? [...] I think it would make sense to be consistent with the Linux builds; we don't bundle compilers with those. In that sense msys2 would be like another distribution.
I'd like that...
9. If I understand correctly, one other thing to consider before dropping ghc-tarballs is that Windows ghc still needs GCC utilities (like cpp) to function properly, [...] Fwiw, at least `cpp` could in theory be replaced by `cpphs` [...]
10. Following the idea in (8), I tried to build ghc using the mingw gcc provided by msys2 instead of the one in ghc-tarballs. It was a bit weird. I had to hack configure.ac to disable use of ghc-tarballs and try to use system tools. How about a configure option to enable/disable use of ghc-tarballs?
Fwiw, Cygwin also provides mingw-gcc (cross)compiler packages to install. So the same could work on Cygwin...
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). [...]
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.
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.