Re: haddock-2.3.0 literate comments discarded from .lhs input

On Wed, 2009-05-27 at 15:10 +0100, Alistair Bayley wrote:

Andrea,

2009/3/19 Andrea Vezzosi :

...

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