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 <jwl...@gmail.com> wrote: > 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 <johan.tib...@gmail.com> > 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 <tuncer.a...@gmail.com> >> wrote: >> >>> On Thu, Dec 18, 2014 at 9:52 AM, Johan Tibell <johan.tib...@gmail.com> >>> 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 >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs