should haddock.ghc be a sub-repo of ghc?
davve at dtek.chalmers.se
Tue Nov 13 08:53:20 EST 2007
> 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 :-)
More information about the Cvs-ghc