The RecompBecause [TH] check is not resume-build-safe
ghc --make aims to make compilation behave correctly and produce up-to-date, no matter whether it completes or is interrupted (e.g. with Ctrl+C) and later resumed
At no point should interrupting a build and running it again produce "less correct" outputs than running it to the end; specifically interrupting shouldn't result in necessary build steps to be "forgotten".
However, this seems to be the case with the
[TH] check introduced in #481 (closed).
Minimal test case with 3 files: https://github.com/nh2/th-recomp-test
Good behaviour when running without interrupting:
% touch A.hs && ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [TH] [3 of 3] Compiling Main ( Main.hs, Main.o ) [TH] Linking Main ...
Bad behaviour when interrupting and running again:
% touch A.hs; timeout 0.1 ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs; ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [TH] Linking Main ...
As you can see, when interrupting, the step
Compiling Main ( Main.hs, Main.o ) [TH] went missing.
This suggests to me that either:
[TH]s are unnecessary in the first place (unlikely and I buy into the reason explained by #481 (closed) that changed values may be picked up by TH in higher-level modules)
- the resumed
ghc --makeinvocation may potentially produce wrong / not-up-to-date outputs (most likely)
- re-running somehow retrieves the information that in fact recompiling
Mainis not necessary for a correct build (if this is the case, then I'd really like to know how that works and we should document it, likely also try to use that way to avoid recompiling
Mainin the uninterrupted run)