Fwd: Is anything being done to remedy the soul crushing compile times of GHC?
andrey.mokhov at newcastle.ac.uk
Thu Feb 18 12:32:59 UTC 2016
Thomas Tuegel <ttuegel at gmail.com> writes:
> > What exactly does the pre-process phase do, anyways?
> It runs the appropriate pre-processor (Alex, Happy, c2hs, etc.) for modules
> that require it. It's slow because of the way the process is carried out: For
> each module in the package description, Cabal tries to find an associated .hs
> source file in the hs-source-dirs. If it cannot, it looks for a file with an
> extension matching one of the pre-processors it knows about. If it finds one,
> it runs the corresponding program if the output files are missing or outdated.
Interesting! In the new Shake-based build system we also need to automagically generate .hs files using Alex et al. My first implementation was slow but then I realised that it is possible to scan the source tree only once and remember where all .hs/.x/etc files are. This brought down the complexity from quadratic to linear in my case -- maybe this could be reused in cabal too?
By the way, there seem to be a fair amount of code & functionality overlap in cabal and the new build system. We might want to look into this once the build system becomes more stable.
More information about the ghc-devs