should haddock.ghc be a sub-repo of ghc?
davve at dtek.chalmers.se
Mon Nov 12 18:16:56 EST 2007
> today i tried to build haddock.ghc from
I've just moved this repository to http://code.haskell.org/haddock,
so point your darcs there for the latest patches.
> with a recent ghc head, and there seem to be some
> odd ends (it starts with not finding 'stringToPackageId'
> and 'packageIdString', then continues with different ideas
> about the arity and type of HsModule).
This is due to recent changes in GHC HEAD. I have some patches to
accommodate for this and some other changes, but I haven't applied them
since they depend on HEAD.
I guess we could #ifdef around this kind of code in Hadddock to support
both 6.8.2 and HEAD. I'm not sure if that would work in the long-run
though. Maybe it would be better to have two repositories: the normal one,
in synch with the latest GHC release, and another one that is in synch
with GHC HEAD.
> i've probably just picked a bad moment for downloading,
> but it made me wonder whether such a tightly integrated
> tool shouldn't be built and maintained in synch with ghc
> my suggestion:
> - keep it as a separate repo, but let darcs-all fetch it
> - build haddock.ghc during ghc's make, but distribute
> it as a separate tool
> that way, it would get daily builds and, more importantly,
> anyone making a change that affects haddock.ghc would
> notice that instantly, and could update it. and those who
> want to use haddock.ghc without ghc, or don't want to
> increase the size of ghc distributions, could still do so.
Well, it certainly is a problem that Haddock often has to be updated
whenever a change is made to the GHC front-end. Wether it should be part
of the boot/extra libraries because of this, I'm not sure.
However, I think it will be hard for Haddock *not* to be part of the GHC
distribution as soon as the GHC build system switches to using it for
documentation. Do the GHC folks have anything to say about this?
More information about the Cvs-ghc