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

[Claus Reinke]

>> I think its likely that if someone makes a change that effects
>> haddock.ghc, then David is the person to fix it up. What I think is
>> more useful is nightly builds, and that isn't just useful for
>> haddock.ghc, its useful for Yhc, Hugs and everything on hackage!
>> Perhaps rather than shove another tool into the GHC tool chain,
>> perhaps someone can setup buildbots in a way that we can easily add
>> projects to the list?
> 
> I agree. We should manage testing the Haskell platform with extra
> general infrastructure and not by integrating all tools into the ghc
> platform.

the point is that haddock.ghc is using the ghc api, which is
(a) an internal api, or at least an api to ghc's internals and
(b) still under rapid development. also, haddock.ghc's
rationale is to be able to haddock ghc haskell, including
ghc's sources.

if someone reshuffles the ghc api, they likely want to know
how that affects any users. if they redefine HsModule, then
suddenly get type errors involving HsModule, they will
probably know how to repair that.

you might disagree with the move towards a ghc-dependent
haddock (are there going to be two independent haddock
lines in future, btw?), but as it stands, it would be difficult
to separate.

one could think of a special list of ghc-api based, but 
not-ghc-core tools, like haddock.ghc, ghctags, .., with
their own buildbots triggered after every day of ghc
updates, but since those tools are intended to be used
on ghc's sources, that would be complicated.

claus