ghci recompilation avoidance

Evan Laforge qdunkan at
Wed May 30 04:41:40 UTC 2018

After switching to git, I discovered that ghci is interpreting a lot of modules
when it should have loaded the .o files (i.e. I get 'SomeModule (interpreted)'
instead of 'Skipped SomeModule').

It turns out that git checkouts update the modtime on checked-out files, even
when they get reverted back to their original contents.  Shake has an option
ChangeModtimeAndDigestInput to check file contents in addition to modtime to not
get fooled by this, but ghc is still doing a plain modtime check.  So shake
correctly skips the rebuild on those modules, but ghci recompiles them anyway.
This means I'm better off just disabling shake's digest check, since otherwise
I can just never recompile that stuff at all.

Would it be reasonable to do the same kind of check as shake in ghc?  Namely,
shake does a quick check if modtime has changed, but even if it has, it checks
the file contents digest to make sure.  My understanding is that ghc does the
quick modtime check, and then does an expensive interface check.  This would
augment that to become a quick modtime check, then a quick-ish digest check,
and then the expensive interface check.

I guess the old input file digest will have to be stored somewhere, presumably
in the .hi file, so it's not a totally trivial change.  The benefit should be
that anyone working with git should be able to reuse more .o files after
branch checkouts.

The two relevant places seem to be GHC.loadModule and DriverPipeline.runPhase.
I'm willing to have a go at this if people think it's a good idea and I can
get some pointers on the .hi plumbing if I get hung up there.

More information about the ghc-devs mailing list