Fw: Cygwin and GHC

[Claus Reinke]

[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" <claus.reinke@talk21.com>
To: "Simon Peyton-Jones" <simonpj@microsoft.com>; <ghc-users@haskell.org>;
<nhc-bugs@haskell.org>
Cc: "C.Reinke" <C.Reinke@ukc.ac.uk>
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 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)?]
>
>