Building ghc on Windows with msys2

[Gintautas Miliauskas]

Hi,

> All we need is someone to act as convenor/coordinator and we are good to
go.  Would any of you be willing to play that role?

Indeed, the next thing I was going to ask was about expediting the decision
process. I would be happy to try and coordinate a push in Windows matters.
There is a caveat though: I don't have any skin in the GHC-on-Windows game,
so I will want to move on to other things afterwards.

An advantage of having a working group is that you can *decide* things.  At
> the moment people often wait for GHC HQ to make a decision, and end up
> waiting a long time.  It would be better if a working group was responsible
> for the GHC-on-Windows build and then if (say) you want to mandate msys2,
> you can go ahead and mandate it.  Well, obviously consult ghc-devs for
> advice, but you are in the lead.  Does that make sense?
>

Sounds great. The question still remains about making changes to code: is
there a particular person with commit rights that we could lean on for code
reviews and committing changes to the main repository?


> I think an early task is to replace what Neil Mitchell encountered: FIVE
> different wiki pages describing how to build GHC on Windows.  We want just
> one!  (Others can perhaps be marked “out of date/archive” rather than
> deleted, but it should be clear which is the main choice.)
>

Indeed, it's a bit of a mess. I intended to shape up the msys2 page to
serve as the default, but wanted to see more testing done before before
dropping the other pages.


> I agree with using msys2 as the main choice.  (I’m using it myself.)  It
> may be that Gintautas’s page
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2
> is already sufficient.  Although I’d like to see it tested by others.  For
> example, I found that it was CRUCIAL to set MSYSYSTEM=MINGW whereas
> Gintautas’s page says nothing about that.
>

Are you sure that is a problem? The page specifically instructs to use the
msys64_shell.bat script (through a shortcut) that is included in msys2, and
that script takes care of setting MSYSTEM=MINGW64, among other important
things.

Other small thoughts:
>
> ·        We started including the ghc-tarball stuff because when we
> relied directly on the gcc that came with msys, we kept getting build
> failures because the gcc that some random person happened to be using did
> not work (e..g. they had a too-old or too-new version of msys).  By using a
> single, fixed gcc, we avoided all this pain.
>

Makes sense. Just curious: why is this less of a problem on GNU/Linux
distros compared to msys2? Does msys2 see comparatively less testing, or is
it generally more bleeding edge?

>
> ·        I don’t know what a “rubenvb” build is, but I think you can go
> ahead and say “use X and Y in this way”.  The important thing is that it
> should be reproducible, and not dependent on the particular Cygwin or gcc
> or whatever the that user happens to have installed.
>
A "rubenvb" build is one of the available types of prebuilt binary packages
of mingw for Windows. Let's figure out if there is something more
mainstream and if we can migrate to that.

-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141002/f5a9cb63/attachment.html>