On Sat, 2008-07-19 at 11:02 +0100, Claus Reinke wrote:
When I issue the command from the subject line in a relatively bare built-from-darcs GHC HEAD on windows, this is what I get:
$ ghc-pkg field '*' haddock-html haddock-html: haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/ghc-prim haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/integer haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/base haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/array .. haddock-html: c:/ghc/ghc-6.9.20080514/html/libraries/ghc haddock-html: c:/ghc/libraries\doc\ghc-paths-0.1.0.1\html haddock-html: c:/ghc/libraries\doc\haskell-src-exts-0.3.4\html haddock-html: "C:\\Program Files\\Haskell\\doc\\uniplate-1.2.0.1\\html"
The first empty line is from rts (as you can confim by using ghc-pkg field '*' name,haddock-html instead), which is correct, as that package has no Haddocks. But note the rest:
- some entries '/', some use '\\', some use a combination of '/' and *unescaped* '\' (the latter two come from ghc's cabal configure run either with or without --prefix)
That's fine. They use \\ when using Haskell String format. When not then windows accepts both \ and / as path separators, it's not an escape char.
- some entries are URLs, some entries are path names
Yeah, that's not good.
- the entry for the ghc package is a lie (the html/ directory doesn't exist, and the doc/html/libraries/ directory has no ghc package docs)
Blame the ghc build system :-)
- while the paths for the core and extra libraries are strictly speaking correct, there is no indication that all of them have been integrated into a unified index (one level up), in contrast to the addon packages, which have their own indices
It would be helpful if the consistency and usefulness of this data could be improved, eg, cabal always using '/' and be consistent in its escape strategy, ghc and cabal using either all URLs or all path names, not adding paths for non-existing docs, and having some indication of whether the package docs have been integrated into some global documentation index.
Cabal uses whatever path the user tells us to use. Whenever Cabal makes up its own paths it uses the standard path separator for the platform. When the path contains spaces it has to use the String format because space is a field separator. So the problems as I see it are why the core packages are using urls. It's not strictly necessary for ghc-pkg to know where index files are that cover various packages but it would be nice to do something better there. People ask for Cabal to maintain an index over all packages though it's not clear where it should put this. Duncan