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
Sent: Thursday, October 2, 2014 22:32
To: Simon Peyton Jones
Cc: Randy Polen, kyra, Marek Wawrzos, Tamar Christina, Roman Kuznetsov, Neil
Mitchell, [email protected]
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
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
