haddock-2.3.0 literate comments discarded from .lhs input

Andrea Vezzosi sanzhiyan at gmail.com
Sun Feb 8 13:18:37 EST 2009

I did work on this and i simplified the code a lot fixing
inconsistencies and making more explicit what how each component
contributes to the arguments to haddock.
Aside from this, should we also do the unliting and cpp from Cabal on
the sources passed to HsColour?

On Fri, Feb 6, 2009 at 11:27 PM, Duncan Coutts
<duncan.coutts at worc.ox.ac.uk> wrote:
> On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote:
>> 2009/2/6 Alistair Bayley <alistair at abayley.org>:
>> >>> [1 of 1] Compiling Test.Fail        ( Test\Fail.hs, Test\Fail.o )
>> >>>
>> >>> Test\Fail.hs:11:26:
>> >>>    Can't make a derived instance of `Typeable Fail'
>> >>>      (You need -XDeriveDataTypeable to derive an instance for this class)
>> >>>    In the data type declaration for `Fail'
>> >>
>> >> Are you processing the above module but it is called Test.Fail in
>> >> reality? Have you stripped out a deriving statement from the example
>> >> above? I'm very confused by this message :)
>> >
>> >
>> > Sorry, my mistake. I pasted the error message from a different
>> > problem. This is the error I get from haddock:
>> >
>> > C:\bayleya\eclipse\workspace\takusen\src>haddock -h --odir=doc Test/Haddock.lhs
>> > Cannot find documentation for: $named_block
>> Okay, then I understand.
>> My guess is (without looking at ghc code) that ghc just throws the
>> literate comments away before lexing the file. This means that the
>> Haddock comments won't be recognized.
>> As you say, there is also an unlitter in Cabal. I don't remember if it
>> is invoked when using Haddock 2, but if it is, it would solve this
>> problem.
> Yes, against my better judgement the code in Cabal for haddock-2.x does
> not run cpp or unliting like it does for haddock-0.x. Instead it assumes
> that haddock-2.x will do all the cpp and unliting itself. Obviously this
> mean the special unliting mode that Cabal provides is not usable with
> haddock-2.x.
> The solution is to do the pre-processing the same for haddock-0.x and
> 2.x. Generally the haddock code in Cabal is a horrible inconsistent
> mess. I believe Andrea Vezzosi has been looking at rewriting it, which
> is good news.
> Duncan

More information about the cabal-devel mailing list