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