Hi all.
What I'm wondering is whether the difficulty is a necessary one, or if it was unintentional, is there an easy fix? From your suggestions, I guess there isn't an easy fix.
I haven't tried this with GHC yet but Earnie Boyd on Sourceforge has recently forked Cygwin to produce a Mingw32 build environment called MSYS. This environment uses the same native Mingw32 gcc as distributed with GHC and is designed to allow the use of native Windows tools within a GNU autotools configuration/build environment. MSYS converts native paths into Posix while executing processes (including Cygwin soft links) and may help your user, Malcolm, to build under Windows while retaining the benefits of a GNU Posix work environment - Makefiles etc. In contrast to Cygwin, executables produced under MSYS are completely normal native Win32 programs (as produced by Mingw32). Most importantly, they depend only on MS Win32 libraries - not on cygwin1.dll or other Posix emulation libraries.
You make it sound as if it isn't possible, which certainly isn't the case - you just have to keep in mind that using filepaths that only makes sense wrt. the Cygwin mount table is not a Good Idea, i.e., stuff like /cygdrive/d/foo. (Have a look at the 'cygpath' utility, btw).
I have already suggested `cygpath' to the user, which is rather ugly but does at least work. One issue for me however, as a distributor of Haskell software, is that I don't want to pollute the installation Makefiles with lots of `cygpath' stuff that is only applicable to one platform. Maybe I can find a relatively painless way to propagate the cygpath calls through a Makefile hierarchy at configure time.
If you're really that gung-ho about cygwin, you could always compile up GHC using the cygwin toolchain.
I avoid Windows altogether myself, but I'll suggest it to the user who had the original complaint.
This is why no-one uses Haskell. (Ooops :)) Cheers Mike Thomas.