----- Original Message ----- From: "Malcolm Wallace" To: "Sigbjorn Finne" Cc: ; ; Sent: Thursday, April 04, 2002 07:30 Subject: Re: [nhc-bugs] Building nhc98 on Windows 2000

...

ghc -package lang -package posix -c \ -o /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/QSort.o \ QSort.hs

Assembler messages: FATAL: Can't create \ \tmp\nhc98-1.12\targets\ix86-CYGWIN_NT-5.0\obj\hmake\QSort.o

So, for whatever reason, that /tmp/... directory doesn't exist.

...

From my reading of the situation, I thought the problem was that the /tmp/... directory *does* exist, but the \tmp\... directory does not. (And indeed, why should it, since the invocation didn't ask for it?)

If the setup in Q had c:\foo\bar\baz mounted as /tmp under cygwin, that might be the case. But surely that's easy enough to work around? --sigbjorn Notice that both GHC and the mingw system calls (the MS provided C runtime functions, really) are capable of understanding paths that contain either "/" or "\" as directory separators, so you're reading too much into the slashes being reversed in that output message.

"Malcolm Wallace" writes:

"Sigbjorn Finne" writes:

...

...

/tmp/... directory *does* exist, but the \tmp\... directory does not. (And indeed, why should it, since the invocation didn't ask for it?)

Notice that both GHC and the mingw system calls (the MS provided C runtime functions, really) are capable of understanding paths that contain either "/" or "\" as directory separators, so you're reading too much into the slashes being reversed in that output message.

So am I right in thinking that if GHC did no internal filepath mangling whatsoever, everything file-related would just work?

Sigh, I thought we'd gone through this before...that's got nothing to do with it - you really should try to stop being so paranoid about the direction of those slashes, Malcolm! :) The story is if I feed GHC a file path that can only be interpreted correctly wrt. a particular application / DLL, GHC will necessarily have problems. Examples include paths that need to be resolved by cygwin's implementation of open(), URLs that need to be interpreted/resolved by a web browser etc. To repeat, this is not a slash-direction issue -- for the case in point, the path could only be resolved by consulting the cygwin mount table for /tmp. --sigbjorn