I think you can summarise all that with "tl;dr the right thing will
happen, you don't have to remember to give any new flags to GHC or Cabal".
Cheers,
Simon
On 09/02/2014 21:14, Austin Seipp wrote:
Actually, just to keep it even simpler, so nobody else is confused
further: Cabal will *also* properly turn on dynamic builds for regular
packages if GHC is dynamic, TemplateHaskell or not. So any library you
compile will still work in GHCi as expected.
So here's the breakdown:
1) Cabal 1.18 will handle dynamical GHCi correctly, including
compiling things dynamically, however it must.
2) Per #1, libraries are compiled dynamically. This means libraries
work in GHCi, just like they did.
3) -Executables- are statically linked by default, still. (But
because of #1 and #2, it's very easy to turn on dynamic exes as well,
without needing to recompile a lot.)
4) TemplateHaskell works as expected due to #1 and #2. But there is
one caveat for executables, noted separately below.
The caveat with TemplateHaskell is for executables: This is because if
you end up with an executable that needs TH and profiling, Cabal must
be aware of this. Why? Because GHCi cannot load *profiled* objects,
only normal ones. So we must compile twice: once without profiling,
and once with profiling. The second compilation will use the 'normal'
objects, even though the final executable will be profiled. Cabal
doesn't know to do this if it doesn't know TemplateHaskell is a
requirement.
Does this clear things up? My last message might give the impression
some things aren't compiled dynamically, because I merely ambiguously
referred to 'packages'.
On Sun, Feb 9, 2014 at 2:37 PM, Austin Seipp <aus...@well-typed.com> wrote:
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
