[nhc-bugs] Re: Cygwin and GHC

[Claus Reinke]

>I am therefore deeply reluctant to provide both GHC-for-mingw32
>and GHC-for-cygwin.   One build on Win32 is enough!   We ended
>up with a mingw32 basis because it meant we could make GHC 
>completely self-contained -- no dependence on cygwin1.dll etc.

Some comments from a binary-only GHC user who tends to depend 
a lot on cygwin while using windows:

>This was *huge* step forward: GHC installs and runs with no problem
>on Windows now.

This *is* a huge step forward, and together with GHCi and HOpenGL,
has even tempted me to use GHC a bit more:-) 

Having to wrestle with two different GHC installations on one platform 
would seem a step backward. So, I'd not only agree with one build 
only (GHC should be compilable under cygwin, though, for those who 
absolutely need to go the other way, or who want to track the CVS
version), I'd like one build to work both in native and in cygwin mode. 
As a Haskell user, I'm interested in:

- a standalone GHC, producing standalone executables and dlls, with
  good FFI interfaces to the non-Haskell world
- portability across platforms, with as few code changes or restrictions
  as possible

My approach to keeping windows/unix differences small is mostly based
on cygwin, so I need to be able to use GHC and it's executables under 
cygwin, as I would use it under unix, in combination with other (windows/
cygwin) software. That doesn't mean that GHC-generated executables or 
libraries need to be cygwin-dependent, and cygwin is, by design, able to 
use windows executables (mixing of libraries is probably another story).

>1.  GHC does not understand cygwin paths in the file names passed
>to it on the command line.

Making GHC understand cygwin paths makes software more system
dependent, not more portable. And what about the executables produced
by GHC? Most of the cygwin path problems could, in theory, be solved 
without changing GHC, but with a lot of accumulated UNIX makefiles, 
that can be unpractical.

As far as I understand, GHC can cope with both relative unix-style and 
relative and absolute windows-styles paths, so the remaining problem I 
tend to encounter are "absolute" unix-style paths which are really relative
to the cygwin root directory. (I also seem to recall someone mentioning 
problems related to GHC passing "normalised" paths to other tools, but
if GHC uses it's own toolchain, that seems unlikely?)

My suggestion would be a --prefix <path> option, or GHC_PATH_PREFIX
variable for GHC-produced executables (including GHC itself), telling them 
that any absolute, unix-style paths are to be interpreted relative to <path> 
(e.g., in cygwin makefiles, default installation, HC=ghc --prefix c:/cygwin). 
That wouldn't be platform-specific and might also come in handy for other 
purposes.

>2.  GHC on Win32 does not come with a Posix library.  If we used a
>Cygwin basis, Posix would be easy because cygwin does all the hard work.

That looks like a real bugger to me as it impacts on portability of Haskell
programs. Going from incomplete posix support to even less posix support
was a step backwards.

>3.  I/O on Win32 is *blocking*.   A blocking input operation freezes all
>the other Haskell threads.

No experience with that one, but in general, establishing consistent I/O 
behaviour across platforms would be a very useful asset.

>Are there any other problems?

perhaps:

4. File I/O on windows differs from I/O in unix (locking of files instead 
    of implicit maintainance of hidden handles, I think??). cygwin tries to 
    smooth things over, but fails for more complex cases (open a file for 
    reading, remove it, open it for writing, copy from read handle to write 
    handle).We just traced a problem in building nhc on cygwin down to 
    that one.. How does mingw fare in that respect? Better? Or even worse?

5. I assume that GHC and it's executables interface rather well with the
    windows world. What about interfacing to software ported from unix
    that depends on cygwin, though?

>1.  GHC already fudges filenames to take account of the Win32/Unix
>conventions.  We could add more fudges, to change /cygwin/c/foo 
>to c:\foo, for example.   Perhaps controlled by a -cygwin flag to tell
>GHC-for-win32 whether to use cygwin fudges or not.  Heuristic, yes;
>but might solve the problem for 99% of customers.

No heuristic, please, just some more flexibility for makefile authors
(/cygwin/c/foo tends to be /cygdrive/c/foo these days, and sometimes
 is //c/foo, but c:/foo tends to work as well - do you want to track
 cygwin's mount table in GHC?-).

>2.  Mingw32 provides quite a lot of Posix, so if someone was prepared
>to put in a bit of work we could get a good part of the Posix library
>available on Win32, still via mingw.  Any volunteers?

I step back to make space for the volunteers, but mingw being minimalistic,
what are the chances that it's posix support is a suitable alternative to 
cygwin's, which isn't complete, either?

>3.  Non-blocking I/O is a soluble problem: Win32 provides suitable
>primitives.  But they are different to the Unix primitives, so there is
>work to do in the runtime system to make it work.  This is harder
>for a volunteer to do because it's in the runtime system, but not 
>impossible.  

As far as I know, cygwin (the *larger* cousin of mingw) is still waiting
for someone to contribute solutions to I/O problems on top of windows..

Thanks for raising this issue,
Claus

PS.
>The GHC core team is now down to Simon M and me.   Sigbjorn
>heroically helps out on Win32 stuff, but it isn't his job.  So we have
>strictly limited effort available.

[I have to admit that I'm a bit concerned about the overall number of 
 people involved in Haskell implementations. Fortunately, the licenses
 are very open, and fortunately, we do have those heroic volunteers,
 but the Haskell implementation core team isn't going to be much (if
 any) bigger than the GHC core team soon. Given the interests of some
 (well, at least one;) companies, and the volunteers working for those,
 perhaps they could acknowledge the work done by those volunteers
 as being essential for their business? And given the wide-spread use 
 in academia as a research and teaching platform, does anyone know 
 of a way of securing some kind of international platform funding, to 
 keep the current implementations alive and to develop them further
 (as an academic complement to Galois' (?) and MS' contributions 
 in terms of man-power)?]