It is correct that Template Haskell now requires dynamic objects. However, GHC can produce static and dynamic objects at the same time, so you don't have to recompile a package twice (it's a big optimization, basically).
Furthermore, if TemplateHaskell is enabled as a requirement for a package, and GHC is built dynamically, Cabal will do The Right Thing by building the shared objects for the dependencies as well. It will save time by doing so using -dynamic-too, if possible. This is because it queries GHC before compilation to figure this out (you can run 'ghc --info' with the 7.8.1 RC to see "GHC Dynamic" and "Supports dynamic-too" fields.) Finally, if you simply run 'ghc Foo.hs' on a file that requires TemplateHaskell, it will also switch on -dynamic-too for the needed objects in this simple case. There is one caveat, if I remember correctly: if a package uses TemplateHaskell, it must declare it as such in the Cabal file. This is because Cabal does not parse the source to detect if TemplateHaskell is needed in the dependency graph of the compiled modules. Only GHC can do this reliably. If you don't specify TemplateHaskell as an extension, Cabal might not do the right thing. This is noted in the release notes: > Note that Cabal will correctly handle -dynamic-too for you automatically, > especially when -XTemplateHaskell is needed - but you *must* tell Cabal you > are using the TemplateHaskell extension. However, based on the other suggestions in the thread and confusion around this, a big "Incompatible changes" section with this listed as the first thing with clear detail would be a good idea. I'll do so. If something else is going on, please file a bug. On Sun, Feb 9, 2014 at 1:37 PM, George Colpitts <george.colpi...@gmail.com> wrote: > Yes, in general I think the doc needs a section: Incompatible changes. The > hope is that you can take the release and just work as usual but when (for > good reasons as in this release) it is not true is is important to have such > a section. Another case that needs to be there is how to compile so you can > load compile object files into ghci as what you did in 7.6.3 won't work in > this release. > > > On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald > <carter.schonw...@gmail.com> wrote: >> >> Indeed. The problem is that many folks might have cabal config files that >> explicitly disable shared. (For the compile times!). They might need clear >> information about wiping that field. >> >> >> On Sunday, February 9, 2014, Brandon Allbery <allber...@gmail.com> wrote: >>> >>> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn <gregmainl...@gmail.com> wrote: >>>> >>>> Is --enable-shared off by default? >>> >>> It's supposed to be on by default in 7.8. That said, not sure how many >>> people have played with ~/.cabal/config.... >>> >>> -- >>> brandon s allbery kf8nh sine nomine >>> associates >>> allber...@gmail.com >>> ballb...@sinenomine.net >>> unix, openafs, kerberos, infrastructure, xmonad >>> http://sinenomine.net >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
