consistency in "ghc-pkg field '*' haddock-html"?

[Duncan Coutts]

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