Spurious recompilations when using a compiler plugin
george.colpitts at gmail.com
Tue Sep 19 14:06:41 UTC 2017
is it possible that this is also connected to
On Tue, Sep 19, 2017 at 10:00 AM Ben Gamari <ben at smart-cactus.org> wrote:
> Conal Elliott <conal at conal.net> writes:
> > It appears that use of GHC plugins causes client code to get needlessly
> > recompiled. (See Trac issues 12567
> > <https://ghc.haskell.org/trac/ghc/ticket/12567> and 7414
> > <https://ghc.haskell.org/trac/ghc/ticket/7414>.) It’s becoming more of a
> > problem for usability of the plugin
> > <http://conal.net/papers/compiling-to-categories> I’ve been developing,
> > I’m wondering what can be done. Some questions:
> > - Is there any work in progress on fixing this situation?
> > - Are there serious obstacles to fixing it?
> > - Do plugin writers or users have any workarounds?
> I think the real question is what sort of interface do plugin authors
> I suspect there are a few distinct tasks here,
> * compute and record module implementation hashes in interface files
> * to include plugin implementation hashes in the recompilation check
> * to provide an interface allowing a plugin to compute a hash of its
> arguments which can be included into the recompilation check. One way
> of realising this would be to add a field like the following to Plugin,
> pluginHash :: [CommandLineOption] -> Maybe Fingerprint
> -- Nothing would denote "always rebuild"
> Would this help in your case?
> This would allow us to fix the TH problem in #7277 and fix the plugins
> problem in #7414 and #12567 in a nearly optimal way (assuming the plugin
> author is able to precisely define a hash).
> None of this is terribly difficult and given Nick's recent work on his
> row types plugin, it seems like it's getting more urgent.
> - Ben
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs