ghc-5.02.2 is not a cygwin application,
Whilst I was aware that GHC no longer requires Cygwin to run, I didn't realise that it actively discourages use under Cygwin.
Don't know where you get this "actively discouraging" bit from.
I'm sorry, I just meant that it seems to be a little bit more difficult now to get GHC and Cygwin to interoperate than it once was. The situation as I understand it is this: * A user has Cygwin as a preferred environment under Windows. * This user has D:\ mounted in Cygwin as /d/. * Most of the user's applications are found in the path /d/. * But a pre-built GHC does not understand the /d/ paths. * The user has tried changing their Cygwin environment to use D:\ instead of /d/. * Now GHC understands paths properly, but most of his other applications now do not work because of the opposite path issue. 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.
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. Regards, Malcolm