should haddock.ghc be a sub-repo of ghc?

[David Waern]

Hi Claus!

> today i tried to build haddock.ghc from
> http://darcs.haskell.org/SoC/haddock.ghc/

I've just moved this repository to http://code.haskell.org/haddock,
so point your darcs there for the latest patches.

> with a recent ghc head, and there seem to be some
> odd ends (it starts with not finding 'stringToPackageId'
> and 'packageIdString', then continues with different ideas
> about the arity and type of HsModule).

This is due to recent changes in GHC HEAD. I have some patches to
accommodate for this and some other changes, but I haven't applied them
since they depend on HEAD.

I guess we could #ifdef around this kind of code in Hadddock to support
both 6.8.2 and HEAD. I'm not sure if that would work in the long-run
though. Maybe it would be better to have two repositories: the normal one,
in synch with the latest GHC release, and another one that is in synch
with GHC HEAD.

> i've probably just picked a bad moment for downloading,
> but it made me wonder whether such a tightly integrated
> tool shouldn't be built and maintained in synch with ghc
> itself.
>
> my suggestion:
> - keep it as a separate repo, but let darcs-all fetch it
> - build haddock.ghc during ghc's make, but distribute
>     it as a separate tool
>
> that way, it would get daily builds and, more importantly,
> anyone making a change that affects haddock.ghc would
> notice that instantly, and could update it. and those who
> want to use haddock.ghc without ghc, or don't want to
> increase the size of ghc distributions, could still do so.

Well, it certainly is a problem that Haddock often has to be updated
whenever a change is made to the GHC front-end. Wether it should be part
of the boot/extra libraries because of this, I'm not sure.

However, I think it will be hard for Haddock *not* to be part of the GHC
distribution as soon as the GHC build system switches to using it for
documentation. Do the GHC folks have anything to say about this?

David