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

[David Waern]

> ok, it seems the consensus on the subject question is "no"
> (fine by me), that ghc api users are on their own with trying
> to follow the api (hmm, ok, i guess), but that ghc api users
> should help with its design (good idea, though i've long had
> my doubts about the "users suggest a good design" part;-).
>
> 1 as for haddock.ghc:
>     i'm still unhappy with the current distribution scheme:
>
>     - as far as i know, haddock.ghc is only distributed in
>         source form, which shouldn't be a problem, but
>
>     - i've got several ghcs on my disk (6.4.1, 6.6.1,
>         clean head for validate, patched head for use) -
>         and, unless i'm misunderstanding something (?),
>         *none of them can be used to build haddock.ghc*!

The code in darcs should work with 6.8.1.

>     - haddock.cabal proclaims no tool dependencies,
>         and its 'build-depends:' says: ghc>=6.8
>
>     even if the cabal file was more accurate, i don't
>     think this is a workable scheme. my preference
>     would be for a darcs repo that works with any
>     ghc>=6.8, but versioned source or binary dists
>     might work as well

Yes, that dependency statement should be more accurate.

Keeping the darcs repository in synch with GHC HEAD is no longer a very
high priority, since GHC 6.8.2 will hopefully have most of what is needed
for Haddock to work right, and a release will be made when it is out.

In the long-run, supporting multiple GHC versions in the same code might
become a headache since the changes to GHC are often quite big. Maybe
Haddock should just change along with GHC for each new major release. You
could then go back to a previous Haddock version if you need to use an old
GHC. Does that sound reasonable?

Then if support for GHC HEAD is really needed, we could have a branch for
it, though as I said it's not a high priority of mine. You are welcome to
send patches though :-)

David