Haddock version during build

[Ian Lynagh]

On Fri, Jun 13, 2008 at 12:27:13AM +0200, David Waern wrote:
> Another issue: If Haddock is built during the GHC installation
> process, does this mean it can only depend on boot packages? And if
> so, would it be out of the question to add more boot packages
> specifically for Haddock?
> 
> I'm asking since it would be *so* useful for Haddock to depend on
> Neil's "derive" package. With this package, one can (soon) derive
> Traversable instances for all of GHC's abstract syntax types. Having
> these instances makes Haddock much easier to maintain. The renamer in
> Haddock, for instance, becomes almost a one-liner and totally
> resistant to changes in GHC's abstract syntax.

We can do this, but I think we should be careful about which library we
choose. There are a number of libraries doing this sort of thing, and we
don't want 3 different parts of the GHC bundle to end up using 3
different ones for no good reason.

If I remember correctly, Neil's only really works with a single
datatype, and I'm therefore not sure it would be a good match for GHC's
mutually recursive datatypes.



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?

It would then be possible to build GHC without haddock, then build
haddock, and then for haddock to haddock the libraries later on using
the info from the .hi file rather than the sources. This wouldn't help
when making the bindists or Windows installer, but it would help the
UNIX distros.


Thanks
Ian