Building ghc on Windows with msys2

Sat Sep 27 21:56:38 UTC 2014

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.