This is due to the way GHC is installed on Windows, the package database doesn't have hardcoded pathnames, the idea being that you can move your GHC anywhere in the filesystem and it will still work.
this is an essential feature (for instance, running GHC from a USB or network drive, or just unpacking snapshots without using installers), please do not start splicing in absolute paths!
Unfortunately this means that Haddock can't find the documentation for the packages.
this part I do not understand - if GHC and ghc-pkg can find the packages, why can't Haddock? wouldn't it just be a case of making $topdir be in a fixed relationship to the output of "ghc --print-libdir"? or should there be a way to query ghc-pkg for the list of package location roots? as you say, the main docs will be in a known location relative to GHC, but perhaps docs in general should be be in a known location relative to their packages, which ghc-pkg (or other tools for other implementations) should be able to locate?
One workaround is to specify the paths by hand, using Haddock's --read-interface flag. You're using Haddock via Cabal though, so that doesn't work too well. The other workaround is to find GHC's package.conf file and replace the string $topdir with the literal path ("c:/ghc/ghc-6.6" in your case - perhaps you have to append "/doc" for the haddock fields, though).
will all docs be moved into "`ghc --print-libdir`\\doc"? what about local/user package databases? Claus _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
