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