Hello! I can only address a small subset of your comments as I don't usually develop on Windows and hence lack any significant Windows experience...
On 2014-09-27 at 23:04:38 +0200, Gintautas Miliauskas wrote: [...] > 2. Since the msys2 setup instructions are so simple and linear, perhaps it > would be even better to put them in a shellscript and check that in? Then > the wikipage would turn into a one-liner. Fwiw, I recently tried msys2, but after wasting several hours I simply couldn't get it to work in a way where I could ssh (tried Freesshd and Winsshd) into an MSYS2 environemnt. Then I simply installed Cygwin against the recommendation, and then I finally got a working ssh-able environment with a few steps, which roughly where OTTOMH: - Install cygwin (make sure 'wget' and 'openssh' gets installed), - grab https://github.com/transcode-open/apt-cyg and place into /usr/local/bin/ - "cygrunsrv" in order to install sshd service - allow 'sshd.exe' in Windows-firewall settings from now on the graphical Windows console/deskopt isn't required anymore (which was my primary goal). Everything else can be done headless/remote via ssh: - `wget` ghc-7.6.3 windows bindist and unpack to /opt/ghc-7.6.3 - prepend /opt/ghc-7.6.3/bin/ and /opt/ghc-7.6.3/mingw/bin/ to user's PATH via ~/.bash_profile or similiar - follow similiar steps to grab cabal and install alex/happy like for MSYS2; you need to pass `--configure-option=--build=x86_64-w64-mingw32` to cabal, though. - apt-cyg install automake git - clone and build ghc as if it was MSYS2 Long-story short, if it wasn't for Cygwin, I wouldn't have been able to clean up after some of the Windows breakage I caused recently. It'd be interesting though if there was a way to `ssh` directly (with a sane terminal-emulation) into an MSYS2 environment capable of building GHC. > 3. Why is ghc-tarballs a git repository? That does not seem very wise. [...] > Could we have a stable folder under haskell.org/ to put the files in, to > make sure that they never go away, and just wget/curl them from there? http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887 > 8. A broader question: what general approach to ghc on Windows shall we > take? [...] > 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. I'd like that... > 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, [...] Fwiw, at least `cpp` could in theory be replaced by `cpphs` [...] > 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 to disable use of ghc-tarballs and try to use > system tools. How about a configure option to enable/disable use of > ghc-tarballs? Fwiw, Cygwin also provides mingw-gcc (cross)compiler packages to install. So the same could work on Cygwin... > 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? The patched in-tree GMP lib isn't necessary anymore with the rewritten integer-gmp2 package (which was one of the motivations to do the rewrite in the first place). [...] > Might be a good idea to put in a guard in the configure script to warn > if a cygwin gcc is detected (or add explicit support for > it). Actually, looks like there's already a related issue open, > although I'm not quite sure what the scope is there (#8842 > <https://ghc.haskell.org/trac/ghc/ticket/8842>, thanks Thomas). It'd be great if one couldn't only use Cygwin as a `build`-environment, but also as the `host`-environment you compile for. > 14. The test runner assumes native Windows Python, but it's only a few > small changes away from working fine on the python2 provided by msys2, > which would cut another external build dependency. Could someone review and > merge my patches (#9604 <https://ghc.haskell.org/trac/ghc/ticket/9604>, > #9626 <https://ghc.haskell.org/trac/ghc/ticket/9626>)? Thanks. Fwiw, the test-runner seems to work fine with the Cygwin-provided Python interpreter. _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
