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