[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