Filter out GHC.Prim also for the Haddock step
simonmarhaskell at gmail.com
Fri Nov 30 08:34:40 EST 2007
Urgh, that's a problem.
There's really no way to typecheck this module as it is, because it is not
the real base:GHC.Prim. The real base:GHC.Prim is in GHC's belly, it has
no source code.
So the only way to get this past the compiler is to change its name. There
are two options: change the package name, or change the module name.
Probably the latter is easier, because otherwise you'd have to make a
separate package (+Cabal bits) for this.
But then you have the problem that the docs are generated with the wrong
module name. So I guess the only way to fix this is to tell Haddock
somehow that it has to change the module name back to GHC.Prim after GHC
has typechecked it.
David Waern wrote:
> What do you think we should do here?
> 2007/11/23, David Waern <david.waern at gmail.com>:
>> 2007/11/17, Ian Lynagh <igloo at earth.li>:
>>> Hi David,
>>> If I understand correctly, your patch
>>> Fri Nov 9 00:08:06 GMT 2007 David Waern <david.waern at gmail.com>
>>> * Filter out GHC.Prim also for the Haddock step
>>> Please merge to the GHC 6.8.2 branch
>>> will remove GHC.Prim from the haddock docs, presumably because haddock 2
>>> can't cope with it? However, the users guide points to it to document
>>> the "Special built-in functions":
>>> and I think it's considered a module that users can import, so it ought
>>> to be documented. Is it possible to make haddock 2 understand GHC.Prim
>> OK, so it's wrong to filter it out in the Haddock 0.x case.
>> In the Haddock 2 case I'm not sure what to do since it seems to be
>> impossible to typecheck this module with GHC. If Haddock 2 can't
>> typecheck a module it can't generate documentation for it.
> Cvs-libraries mailing list
> Cvs-libraries at haskell.org
More information about the Cvs-libraries