On 27/09/2014 22:04, Gintautas Miliauskas wrote:
8. A broader question: what general approach to ghc on Windows shall we
take? The prebuilt packages currently provided by ghc-tarballs are also
covered by msys2's package manager. Why not offload that pain to msys2
then? The advantage here is less maintenance (and automatic upgrades of
the toolchain), the disadvantage is that the distribution becomes less
stable and msys2 updates could break ghc builds more easily. I think it
would make sense to be consistent with the Linux builds; we don't bundle
compilers with those. In that sense msys2 would be like another
distribution. Of course, we need to also consider if msys2 can be
trusted to stick around and stay up to date in the long run. It looks
like a relatively new project, so there's some risk.
9. If I understand correctly, one other thing to consider before
dropping ghc-tarballs is that Windows ghc still needs GCC utilities
(like cpp) to function properly, and so we need to have a prepackaged
bundle of binary GCC utilities (and maybe hardcoded paths? not sure) to
make that work. On the other hand, a custom-built ghc should work just
fine in the msys2 environment which does provide cpp et al., and the
additional GCC bundles would perhaps best be owned by, for example, the
Haskell Platform project rather than be part of core ghc?
10. Following the idea in (8), I tried to build ghc using the mingw gcc
provided by msys2 instead of the one in ghc-tarballs. It was a bit
weird. I had to hack configure.ac <http://configure.ac> to disable use
of ghc-tarballs and try to use system tools. How about a configure
option to enable/disable use of ghc-tarballs? I also ran into some weird
issues, for example, the system ld and nm would not get detected by the
configure script correctly. They were found when I explicitly set LD=ld
and NM=nm. Weird. Will look into that later. Other than that, there were
no major problems, except...
11. A build with the host gcc failed. I think the cause is that it is
too new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The
build of the currently checked in GMP (libraries/integer-gmp) fails
because a utility used in the build process segfaults. I tried upgrading
gmp from 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but the
ghc-specific patch used for 5.0.3 no longer applies (is it still
necessary?). Oh brother. One of the advantages of tracking msys2's gcc
would be that we would notice such breakage earlier. Shall I open an issue?
We created ghc-tarballs for stability reasons. In the past, some
versions of mingw were broken, so we wanted to ensure that everyone
building GHC on Windows was using the same gcc, and that a given build
of GHC will ship with a predictable gcc, rather than grabbing whatever
is installed.
I think it's pretty important that GHC can be installed independently of
mingw. That dependency used to be huge source of pain when we had it.
Windows is unlike Linux, in that on Linux it's easy to install a working
gcc. Many distributions already ship it, and even when they don't, the
package manager makes it easy to add gcc as a dependency of GHC so it
gets installed automatically.
Cheers,
Simon
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
