Building ghc on Windows with msys2

Fri Oct 10 20:01:00 UTC 2014

Hey,

I have created https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce, and
added the two people from whom I heard a confirmation that they want to be
on the list. Please edit the page and add yourself if you should be on that
list. Feel free to hack the page up and add additional info as you see fit.

On Thu, Oct 9, 2014 at 9:51 AM, Simon Peyton Jones <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]
> *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
> *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 <gintautas.miliauskas at gmail.com>
> *Sent:* ‎Thursday‎, ‎October‎ ‎2‎, ‎2014 ‎22‎:‎32
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Randy Polen <randyhaskell at outlook.com>, kyra <kyrab at mail.ru>, Marek
> Wawrzos <marek.28.93 at gmail.com>, Tamar Christina <lonetiger at gmail.com>, Roman
> Kuznetsov <kuznero at hotmail.com>, Neil Mitchell <ndmitchell at gmail.com>,
> 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
>

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