[GHC] #14298: Let Template Haskell dynamically add something with which to link

[GHC]

#14298: Let Template Haskell dynamically add something with which to link
-------------------------------------+-------------------------------------
        Reporter:  harpocrates       |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Template Haskell  |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 > That said, my understanding of `-c` is that it shouldn't work on any
 module that uses TH from another module.

 That isn't quite true. TH will work perfectly well in single-shot mode.
 However, as usual, the user must guarantee that any needed modules are
 compiled for whatever way GHC will want to load to evaluate splices.

 For instance,
 {{{
 $ pwd
 /opt/exp/ghc/ghc-landing/testsuite/tests/th
 $ ghc -c TH_NestedSplices_Lib.hs  -dynamic-too -fforce-recomp
 $ ghc -c TH_NestedSplices.hs -fforce-recomp
 }}}

 It's important that this behavior be preserved since Cabal is slowly
 moving towards using single-shot mode to improve module-level build
 parallelism.

 > About the API, I would prefer:
 > {{{
 > addForeignObject :: ByteString -> Q ()
 > }}}

 The interface in comment:6 sounds plausible.

 The worry that I have with just allowing the user to specify an object
 file path as in the original proposal is that it makes it seem as though
 they can safely `addForeignObject` the same object file from multiple
 modules. However, this is not safe as they will encounter conflicting
 symbol errors when they attempt to link the final object. Of course, we
 could in principle document our way out of this issue.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14298#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler