> <font size="2"><span style="background-color:rgba(255,255,255,0)">It turns out that git checkouts update the modtime on checked-out files, even<br>when they get reverted back to their original contents.</span></font><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">Looks to me the problem's right here. Namely, git checkout.</span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">If the contents didn't change, the modtime shouldn't either. What's the reason behind changing it?</span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">Have you brought this up to the git maintainers? Compensating for flaws in co-tools costs code and complexity in ghc we would rather do without.</span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">In the meantime, it shouldn't be hard to kludge up some shell scripts that run before and after git checkout to reset the modtime back to what it should be.<br></span></font><br>On Wednesday, May 30, 2018, Evan Laforge <<a href="mailto:qdunkan@gmail.com">qdunkan@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">After switching to git, I discovered that ghci is interpreting a lot of modules<br>
when it should have loaded the .o files (i.e. I get 'SomeModule (interpreted)'<br>
instead of 'Skipped SomeModule').<br>
<br>
It turns out that git checkouts update the modtime on checked-out files, even<br>
when they get reverted back to their original contents.  Shake has an option<br>
ChangeModtimeAndDigestInput to check file contents in addition to modtime to not<br>
get fooled by this, but ghc is still doing a plain modtime check.  So shake<br>
correctly skips the rebuild on those modules, but ghci recompiles them anyway.<br>
This means I'm better off just disabling shake's digest check, since otherwise<br>
I can just never recompile that stuff at all.<br>
<br>
Would it be reasonable to do the same kind of check as shake in ghc?  Namely,<br>
shake does a quick check if modtime has changed, but even if it has, it checks<br>
the file contents digest to make sure.  My understanding is that ghc does the<br>
quick modtime check, and then does an expensive interface check.  This would<br>
augment that to become a quick modtime check, then a quick-ish digest check,<br>
and then the expensive interface check.<br>
<br>
I guess the old input file digest will have to be stored somewhere, presumably<br>
in the .hi file, so it's not a totally trivial change.  The benefit should be<br>
that anyone working with git should be able to reuse more .o files after<br>
branch checkouts.<br>
<br>
The two relevant places seem to be GHC.loadModule and DriverPipeline.runPhase.<br>
I'm willing to have a go at this if people think it's a good idea and I can<br>
get some pointers on the .hi plumbing if I get hung up there.<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br><br>-- <br>-- Kim-Ee<br>