Building ghc on Windows with msys2

[Simon Peyton Jones]

Better to continue on ghc-devs; that way others have visibility of what is going on.

Simon

From: Gintautas Miliauskas [mailto:gintautas.miliauskas at gmail.com]
Sent: 09 October 2014 10:29
To: Simon Peyton Jones
Cc: Neil Mitchell; Randy Polen; Roman Kuznetsov; lonetiger at gmail.com; ghc-devs at haskell.org; kyra; Marek Wawrzos
Subject: RE: Building ghc on Windows with msys2


I'll set up a wikipage this evening.

Should we get a mailing list of our own too, or do you think it's best to continue on ghc-devs@?

--
Gintautas Miliauskas
On Oct 9, 2014 9:52 AM, "Simon Peyton Jones" <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I think I’m fairly behind on the current build process of GHC, but as I do use GHC mainly on Windows, at such a time as you would like to move on to other things, I would certainly throw my hat In the ring.

That sounds helpful, thank you.

Are we at the point where we could form a GHC-on-Windows Task Force?  With its own wiki page on the GHC Trac, and with named participants.  (Of course you can drop off again.)  But it would be really helpful to have an explicit group who feels a sense of ownership about making sure GHC works well on Windows.  At the moment we are reduced to folk memory “I recall that Gintautas did something like that a few months ago”.

It sounds as if Tamar would be a willing member.  Would anyone else be willing?    I’d say that being a member indicates a positive willingness to help others, along with some level of expertise, NOT a promise to drop everything to attend to someone else’s problem.

Simon

From: lonetiger at gmail.com<mailto:lonetiger at gmail.com> [mailto:lonetiger at gmail.com<mailto:lonetiger at gmail.com>]
Sent: 09 October 2014 06:04
To: Gintautas Miliauskas; Simon Peyton Jones
Cc: Randy Polen; kyra; Marek Wawrzos; Roman Kuznetsov; Neil Mitchell; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Building ghc on Windows with msys2

Hi Gintautas,

>  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.

I think I’m fairly behind on the current build process of GHC, but as I do use GHC mainly on Windows, at such a time as you would like to move on to other things, I would certainly throw my hat In the ring.

Cheers,
Tamar


From: Gintautas Miliauskas<mailto:gintautas.miliauskas at gmail.com>
Sent: ‎Thursday‎, ‎October‎ ‎2‎, ‎2014 ‎22‎:‎32
To: Simon Peyton Jones<mailto:simonpj at microsoft.com>
Cc: Randy Polen<mailto:randyhaskell at outlook.com>, kyra<mailto:kyrab at mail.ru>, Marek Wawrzos<mailto:marek.28.93 at gmail.com>, Tamar Christina<mailto:lonetiger at gmail.com>, Roman Kuznetsov<mailto:kuznero at hotmail.com>, Neil Mitchell<mailto:ndmitchell at gmail.com>, ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>

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/20141009/6442d8c4/attachment-0001.html>