haddock-2.3.0 literate comments discarded from .lhs input

[David Waern]

2009/3/18 Alistair Bayley <alistair at abayley.org>:
>> Ok, all of Andrea's haddock changes are in Cabal HEAD now, so if you'd
>> like to look at the .lhs situation now that'd be great.
>
> I've finally tested this. It looks like Distribution.Simple.Haddock
> module does what I want; now I just have to deal with the haddock
> problems.
>
> BTW, would it be a good idea to add (yet) another cabal flag that
> retains temp files/directories? This would make it a lot easier to
> diagnose issues with preprocessed source without having to modify and
> rebuild cabal.
>
> The 2 haddock problems I have now are:
>
> (1) When cabal calls haddock it passes:
>
> --read-interface=$httptopdir/doc/libraries/base,c:\ghc\ghc-6.10.1/doc/libraries/base\base.haddock
>
> This results in links in the html docs like this (e.g. for Either):
> file:///C:/bayleya/eclipse/workspace/takusen/src/dist/doc/html/Takusen/$httptopdir/doc/libraries/base/Data-Either.html#t%3AEither
>
> i.e. the $httptopdir isn't being expanded, or whatever is meant to happen to it.
>
> Is this a haddock issue, or a cabal issue?

Haddock doesn't expand this variable. I remember seeing code to expand
it in Cabal, though. Maybe it's just not used for Haddock 2?

Could be something we want to support in Haddock in the future,
though. For example to allow a --package flag, to avoid having to
specify files directly using --read-interface. Then Haddock needs to
be able to expand this variable.

> (2) Also, there seems to be a bug in Haddock where preformatted text
> in the HTML output
> has extra CR inserted before the CRLF. Presumably this only affects
> Windows users. I assume I should raise this with Gwern.

This is fixed in the soon-to-be-released GHC 6.10.2.

David