I installed ghc-6.8.2 with USE=doc, but apparently the ebuild does not rebuild the haddock documentation. It certainly does not rebuild the haddock interface files, because those files have a timestamp from back in December although I installed them 30 minutes ago: peti:~$ cd /usr/share/doc/ghc-6.8.2/libraries/base/ peti:/usr/share/doc/ghc-6.8.2/libraries/base$ ls -l base.haddock -rw-r--r-- 1 root root 258712 Dec 14 11:12 base.haddock Is there a reason for this? I wonder because those interface files have been compiled with a rather old version of haddock, so they are incompatible to the ones generated by the version I have installed. If those files would be re-built with whatever haddock version is found on the system, this wouldn't be an issue. Reproducible: Always
What USE flags have been set (USE=ghcbootstrap particularly)? Your `emerge --info' and `emerge -vp ghc', please.
If the USE=binary flag is set the installation will simply unpack and install without compiling or rebuilding anything. Did you use this? If so, try to build with USE="doc -binary" and report back, please. USE=ghcbootstrap is only used to make new ghc-bin packages, but I don't think you used it.
Hey, thanks for the quick responses! I re-emerged dev-lang/ghc with USE=ghcbootstrap, which hadn't been set previously, and that did the trick. This time, the haddock interface files have been re-built. It never occurred to me to try this flag, because I associated the name "ghc bootstrapping" with the bootstrapping procedure GHC uses when it's being ported to new architectures, which is a really low-level thing, but apparently that's not what this flag is about. The key to everything are the following lines in the ebuild: if use ghcbootstrap && use doc; then echo XMLDocWays="html" >> mk/build.mk echo HADDOCK_DOCS=YES >> mk/build.mk else echo XMLDocWays="" >> mk/build.mk fi I'm not sure that's the best way to handle the situation. Apparently, the ebuild doesn't want to depend on Haddock unless the bootstrap flag is set. I feel that's sensible, but I also believe that the ebuild should take advantage of Haddock if it _is_ installed. If nothing else, the ebuild should issue a warning when it finds an installed haddock version that differs from the version that was used to build the binary package -- i.e. any version other than haddock 0.8 in our case. Anyway, I'm glad that the problem was that simple to fix. ;-) Thanks again for helping me out.
