On 20/03/14 16:08, Edward Kmett wrote:
One strong reason for considering at least including the haddocks in the .hi files is build times.
Currently if you have cabal configured to build and document every package running hackage requires you to recompile your entire source tree a second time to get information that we just dropped on the floor before spitting out the .hi file.
For most of the users of GHC this is a 50% difference in compile times if they have cabal configured to generate haddocks.
GHC doesn't have to understand the haddocks any more than it does now to support it, just include the content.
Haddock could then just go through and load the .hi files rather than starting from scratch with parsing and typechecking the entire module, running template-haskell, just to get at the documentation.
Any pythonesque :doc command support to me would be gravy.
The reason I care at all is the build times. I regularly lose minutes out of each build just to regenerate docs and wind up skipping building them as much as I can get away with to avoid he pain.
-Edward
As Simon M points out, we still have to run the renamer which seems to be tightly bound with the type-checker. Where do you suggest the sizeable performance increase would be coming from in this case? For all the existing packages, we already read the docs from .haddock files so there's no difference there. For new packages we have to type-check and generate .haddock anyway so there's no difference there either. It's not really about GHC having to know more about Haddock, it's about Haddock having to use GHC anyway, whether the strinsg are embedded or not. -- Mateusz K.