> 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 _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
