Haddock version during build
isaacdupree at charter.net
Mon Jun 16 07:21:36 EDT 2008
Simon Marlow wrote:
> David Waern wrote:
>>> Another thing to think about is these bugs:
>>> about giving docs for things reexported from another package. One way to
>>> fix this would be for GHC to put the doc info in the .hi file (or
>>> another auxiliary file); I think GHC can already parse the info?
>> Yes, although putting the doc info in the .haddock file would also work.
> Putting it in the .haddock file seems right to me, given that we want to
> move as much knowledge of Haddock documentation from GHC into Haddock as
> possible. The problem with putting the documentation in the .hi would
> be that it needs to be renamed, and in order to do that GHC would have
> to understand the markup. It currently does understand the markup, but
> we wanted to move that knowledge out of GHC and into Haddock.
> However this does mean that we need to run haddock at library build
> time, and can't leave it until later as Ian suggests.
is there a reason not to put the .hs (rather than a .haddock) with the
.hi, so it can be processed later with haddock? (some sort of inefficiency?)
More information about the Cvs-libraries