Haddock version during build

Simon Marlow marlowsd at gmail.com
Tue Jun 17 05:38:40 EDT 2008


Isaac Dupree wrote:
> Simon Marlow wrote:
>> David Waern wrote:
>>
>>>> Another thing to think about is these bugs:
>>>>    http://hackage.haskell.org/trac/ghc/ticket/1269
>>>>    http://hackage.haskell.org/trac/ghc/ticket/2337
>>>> 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?)

You don't really want to process the whole source of every dependent 
package (including base) each time you need to run haddock over a new 
package.  Or have I misunderstood?

Cheers,
	Simon


More information about the Cvs-libraries mailing list