[GHC] #13237: Extend TH with addModCStub
GHC
ghc-devs at haskell.org
Fri Feb 10 22:00:30 UTC 2017
#13237: Extend TH with addModCStub
-------------------------------------+-------------------------------------
Reporter: | Owner:
facundo.dominguez | facundo.dominguez
Type: feature request | Status: patch
Priority: normal | Milestone: 8.2.1
Component: Template Haskell | Version: 8.0.1
Resolution: | Keywords: inline-c
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D3106
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by nh2):
Replying to [comment:17 facundo.dominguez]:
> I follow this far. Now that the hash is in the .hi file, how does GHC
know to recompile `A.hs` the next time `header.h` changes?
Ah, now I get what you're thinking about. No, cannot notice when it has to
recompile A.hs when includes change; it would have to be the CPP to notice
that (or ask the CPP what files it read, or run the CPP unconditionally).
I was suggesting (but you're right, I didn't actually state it) that
*when* we recompile A.hs, and notice `mystring` is unchanged (which would
usually result in further compilation being avoided), we can invalidate
*downstream* modules of `A.hs` based on the includes, even when the
unexpanded argument `mystring` of `addModCStub` doesn't change. Sorry for
the confusion.
The value this would add is that you can touch (or save the buffer) of the
module that contains the Haskell string to force a proper non-avoided
build when (you know that) includes changed, as opposed to e.g. having to
stack/cabal clean the entire project.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13237#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list