
I think that results in libs being built the dyn way as well, which
probably doesn't hurt but takes quite a bit of time.
On Tue, Dec 30, 2014 at 4:07 PM, John Lato
I don't have an authoritative answer, but in the past I set DYNAMIC_GHC_PROGRAMS and DYNAMIC_BY_DEFAULT as Johan originally suggested and didn't have any issues with the resulting build.
On Tue Dec 30 2014 at 9:00:07 AM Johan Tibell
wrote: Not a good answer, I just set
GhcLibWays = v DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO
at the bottom of the file. This feels a bit hacky because we're overriding GhcLibWays (e.g. we could be dropping the prof way by accident). I think it should be possible to state our desire (i.e. I don't want dyn) somewhere in the file and have that just work. Trying to manually change things like GhcLibWays is error prone.
On Tue, Dec 30, 2014 at 11:48 AM, Tuncer Ayaz
wrote: On Thu, Dec 18, 2014 at 9:52 AM, Johan Tibell
wrote: Some times when I play around with GHC I'd like to turn off dynamic linking to make GHC compile faster. I'm not sure what the right way to do this in build.mk. It's made confusing by the conditional statements in that file:
GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v)
This line make me worry that if I don't put
DYNAMIC_GHC_PROGRAMS = NO
in the right place in build.mk it wont "take".
There's also this one:
ifeq "$(PlatformSupportsSharedLibs)" "YES" GhcLibWays += dyn endif
Seeing this makes me wonder if
DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO
is enough or if the build system still sniffs out the fact that my platform supports dynamic linking.
Could someone please give an authoritative answer to how to turn off dynamic linking?
Hi Johan,
did you find the answer?
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs