Cygwin and GHC

Simon Peyton-Jones simonpj@microsoft.com
Thu, 4 Apr 2002 02:12:06 -0800


Folks,

There's been some mail recently about GHC and Cygwin, some
of it on the nhc-bugs list (hence ccing this there).  I'm a bit confused
so this message is to try to clarify the situation.


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 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=20
completely self-contained -- no dependence on cygwin1.dll etc.
This was *huge* step forward: GHC installs and runs with no problem
on Windows now.

Therefore I ask:

	can someone summarise succinctly what the
	problems with GHC-for-mingw32 are?

The ones I know about are these:

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

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.

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

Are there any other problems?


My own ill-informed thoughts on these are:

1.  GHC already fudges filenames to take account of the Win32/Unix
conventions.  We could add more fudges, to change /cygwin/c/foo=20
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.

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?

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=20
impossible. =20


Any thoughts?  Ideas are much more likely to be implemented if
they are either easy, or you can help do the job!

Simon