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
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
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
impossible.
Any thoughts? Ideas are much more likely to be implemented if
they are either easy, or you can help do the job!
Simon
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
