[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 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)?] > > _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users