[interesting; postfix at haskell.org claims rightly that there is no ghc-users
list there.
so how did Simon's mail reach me in the first place? well, here we go again]
- Original Message -
From: Claus Reinke [EMAIL PROTECTED]
To: Simon Peyton-Jones [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Cc: C.Reinke [EMAIL PROTECTED]
Sent: Thursday, April 04, 2002 1:45 PM
Subject: Re: Cygwin and GHC
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
