On Sat, Oct 4, 2008 at 5:01 PM, Joachim Breitner <[EMAIL PROTECTED]> wrote:
> Hi, > > I'd like to bring up > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464364 > again, because haddock 2 has some features I'd really like to see. > > From what I'm reading in > http://www.haskell.org/pipermail/cvs-ghc/2008-June/042779.html > haddock 2 can only work on files that were compiled with the version of > ghc that haddock was compiled with itself. Is that right? > > The problem is then that during the build of a new ghc6 source (which > includes building the docs for that), the old haddock used to build > documentation, which then fails. Is that right as well? > > What solutions are possible? I can think of: > 1. Including haddock in the ghc6 source. > 2. Not building the ghc6 docs during the ghc6 build, but from a > separate source file, so that ghc6 can be built, then a new haddock > version, and then the docs for everything. > 3. Ignoring haddock errors in the ghc6 build process, and re-building > the ghc6 packages after haddock has built against the new ghc6 (assuming > that the internal GHC version does not change just by re-building ghc). > 4. Finding a way for haddock to work independent of the ghc6 that has > built the files. > > > Anything that we can rule out? Anything that sounds reasonable? I'm no > expert in this matter, so I'd like to hear your opinion. > > Greetings, > Joachim For our repository, I do the following: 1. Build the new haddock with the old GHC 2. Build a patched version of GHC with the documentation disabled 3. Build patched versions of cabal and ghc-paths with the documentation disabled 4. Rebuild haddock with the new GHC 5. Rebuild GHC with the documentation enabled 6. Build everything (except haddock) It was also necessary to patch all the library source debs so that the documentation packages were architecture "any" instead of architecture "all", since the haddock files are also architecture dependent, or at least don't consider the GHCs from different architectures to match.
