My knowledge of precisely how haddock works is somewhat fuzzy in that it
arises from a series of discussions a couple of years back.
My observation was mostly that I run 'cabal install' it goes through all
the modules building my .hi files, etc. Then I run cabal haddock and it
spends all that time redoing the same work, just to go through and get at
some information that we had right up until the moment we finished building.
I'm not wedded to bolting the information into the .hi files being the
solution, but the idea that we could avoid redoing that work is
tantalizing. I'm mostly trying to avoid redoing all the same work twice in
the build cycle of the average user.
If there is an alternative strategy, such as, oh, I don't know, making
haddock able to hook in plugin-style late as we're generating the .hi file
to spit out what it needs to something else and interrogate/rename/whatever
it needs the rest of the GHC API I'd be totally open that as well.
-Edward
On Thu, Mar 20, 2014 at 12:18 PM, Mateusz Kowalczyk 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 On 20/03/14 16:08, Edward Kmett wrote:
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.