Hi > 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.
It's an exported, stable, documented and supported API - or at least I believe that is the eventual intention. > 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. I have GHC API based tools, which do various things. I don't think any of them should be integrated into the GHC build tree, or even hosted on darcs.haskell.org. If we don't make a clear separation between GHC and the users of the GHC API, then we don't really have an API. Hopefully, in time, the pain associated with using the GHC API will reduce. Thanks Neil _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
