haddock-2.3.0 literate comments discarded from .lhs input

[Duncan Coutts]

On Wed, 2009-05-27 at 15:10 +0100, Alistair Bayley wrote:
> Andrea,
> 
> 2009/3/19 Andrea Vezzosi <sanzhiyan at gmail.com>:
> > 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.
> 
> Do you (or anyone else) intend to work on this? If not, I'd like to
> fix it, but I'll need some guidance. Like, is
> Distribution.Simple.GHC.getInstalledPackages where the variable
> expansion code should go, or should it be somewhere else?

I don't think we should be hacking around this in Cabal without any
discussion with the ghc folks on what is supposed to be there, what
variables are allowed.

We need a clear spec on what variables tools are expected to handle and
how they are to be interpreted. The output of ghc-pkg describe/dump is
not just for ghc to define and play around with. It's supposed to be
defined by the Cabal spec.

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. 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. That makes
sense beyond just ghc and even with would allow other sets of
relocatable packages, not just those installed with ghc.

Then perhaps as a compat hack we should get Cabal to handle older ghc
versions that do use these funny vars.

Duncan