haddock-2.3.0 literate comments discarded from .lhs input

[Claus Reinke]

>> > It turns out that those variables are there to allow relocation, in
>> > fact $topdir is expanded by
>> > Distribution.Simple.GHC.getInstalledPackages, it seems that
>> > $httptopdir has been overlooked.
>> > I'd be tempted to say that it's ghc-pkg dump/describe responsibility
>> > to expand those vars instead, like it does for ghc-pkg field.

Agreed on ghc-pkg doing the translation. Via commandline options, 
or via environment vars (one might be tempted to manage the bindings
in ghc-pkg's database itself, even). The lack of support for this hampers 
the useability of ghc-pkg and the database it is responsible for.

> We need a clear spec on what variables tools are expected to handle and
> how they are to be interpreted. 

Currently, there seem to be $topdir and $httptopdir. Given the split
between GHC and HP, it might be useful to have an additional $hptopdir,
or just a general mechanism for variables in ghc-pkg's database (I recall
being disappointed when what looked like environment variables were
unaffected by environment settings..).

The info is somewhat distributed:
    http://darcs.haskell.org/ghc/utils/ghc-pkg/Main.hs
    http://darcs.haskell.org/ghc/compiler/main/Packages.lhs
    http://darcs.haskell.org/ghc/compiler/main/SysTools.lhs [Note topdir]

> Supporting relocatable sets of packages is a good idea. We should aim to
> have something that is usable by each compiler, not just ghc, so
> interpreting paths relative to ghc's libdir doesn't seem ideal. 

GHC makes no reference to libdir, it simply talks about a $topdir
(where it would like to store things it needs) and $httptopdir (where
haddocks might be found).

> How
> about this: a way to specify paths in the package registration info that
> are relative to the location of the package db they are in. 

ahem. That sounds like a backwards step, being dependent on two
locations instead of one. Before the HP, windows GHCs could be
relocated without needing to update the ghc-pkg database, even if
some packages were installed outside GHCs $topdir. With your
variant, just about any change would need updating. Assuming that 
the parts are independently located by whatever the OS packaging 
conventions say, and can be independently relocated otherwise, it 
seems simpler to continue with the variable scheme, but with 
improved support and documentation for it.

Claus