ghc/cygwin filename resolution issue.
Fri, 31 Jan 2003 00:40:13 -0000
>As Simon M says, if you (or anyone else) felt able to write up a
>standalone summary of what the problem is, and what the solution is, I'd love
>to add it to the GHC FAQ or documentation somewhere.
Following the worse-is-better approach, here's some text for others
to fiddle with (I'd recommend to keep the result in the GHC FAQ
proper, possibly with a link from the building guide, if necessary).
I've omitted the build-ghc-with-cygwin option, lest readers in search
or solutions rush of to cause themselves even more problems;-).
Using GHC (and other GHC-compiled executables )with cygwin
The cygwin tools aim to provide a unix-style API on top of the windows
libraries, to facilitate ports of unix software to windows. To this end, they
introduce a unix-style directory hierarchy under some root directory
(typically / is C:\cygwin\). Moreover, everything built against the cygwin
API (including the cygwin tools and programs compiled with cygwin's
ghc) will see / as the root of their file system, happily pretending to work
in a typical unix environment, and finding things like /bin and /usr/include
without ever explicitly bothering with their actual location on the windows
system (probably C:\cygwin\bin and C:\cygwin\usr\include).
GHC, by default, no longer depends on cygwin, but is a native windows
program. It is built using mingw, and it uses mingw's ghc while compiling
your Haskell sources (even if you call it from cygwin's bash), but what
matters here is that - just like any other normal windows program - neither
GHC nor the executables it produces are aware of cygwin's pretended
unix hierarchy. GHC will happily accept either '/' or '\' as path separators,
but it won't know where to find /home/joe/Main.hs or /bin/bash or the
like. This causes all kinds of fun when GHC is used from within cygwin's
bash, or in make-sessions running under cygwin.
[things to do]
0) don't panic!
1) don't use absolute paths in make, configure & co if there is any chance
that those might be passed to GHC (or to GHC-compiled programs). Relative
paths are fine because cygwin tools are happy with them and GHC accepts
'/' as path-separator. And relative paths don't depend on where cygwin's
root directory is located, or on which partition or network drive your source
tree happens to reside, as long as you 'cd' there first.
2) if you have to use absolute paths (beware of the innocent-looking
ROOT=`pwd` in makefile hierarchies or configure scripts), cygwin provides
a tool called 'cygpath' that can convert cygwin's unix-style paths to their
actual windows-style counterparts. Many cygwin tools actually accept
absolute windows-style paths (remember, though, that you either need
to escape '\' or convert '\' to '/'), so you should be fine just using those
everywhere. If you need to use tools that do some kind of path-mangling
that depends on unix-style paths (one fun example is trying to interpret ':'
as a separator in path lists..), you can still try to convert paths using
cygpath just before they are passed to GHC&friends.
3) if you don't have cygpath, you probably don't have cygwin and hence
no problems with it.. unless you want to write one build process for several
platforms. Again, relative paths are your friend, but if you have to use
absolute paths, and don't want to use different tools on different platforms,
you can simply write a short Haskell program to print the current directory
(thanks to George Russell for this idea): compiled with GHC, this will give
you the view of the file system that GHC depends on (which will differ
depending on whether GHC is compiled with cygwin's gcc or mingw's
gcc or on a real unix system..) - that little program can also deal with
escaping '\' in paths. Apart from the banner and the startup time,
something like this would also do:
$ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci
4) panic now.