If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Extra modules: CoreOpt make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Is it necessary to have two places to extend? Simon
That's correct: if you add a module which is (indirectly) imported by DynFlags, you have to tell ghc.mk about it so that the Windows DLL splitting hack continues to work. Edward Excerpts from Simon Peyton Jones via ghc-devs's message of 2017-03-16 17:49:43 +0000:
If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits
If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a
Reachable modules from DynFlags out of date
Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
Extra modules: CoreOpt
make[1]: *** [compiler/stage2/dll-split.stamp] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
Is it necessary to have two places to extend?
Simon
My current patch on phabricator.haskell.org does do away with this and
instead implements an automatic partitioning scheme which also scales.
I have just not resolved all the issues yet to be able to push it with
dynamic linking on. Although it might be worth for me to disable dynamic
linking and push the current one as to get dll-split gone and to make the
required build system changes.
On Thu, 16 Mar 2017, 18:03 Edward Z. Yang,
If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits
If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a
Reachable modules from DynFlags out of date
Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
Extra modules: CoreOpt
make[1]: *** [compiler/stage2/dll-split.stamp] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
Is it necessary to have two places to extend?
Simon
ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Simon Peyton Jones via ghc-devs
If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits
If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a
Reachable modules from DynFlags out of date
Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
Extra modules: CoreOpt
make[1]: *** [compiler/stage2/dll-split.stamp] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
Is it necessary to have two places to extend?
Well, I suppose we might be able to compute the list of accessible modules instead of listing them by hand. However, I'm not sure that this would be worth the complexity it would introduce. Moreover, I believe that Tamar is working towards being able to entirely lift the need for this list (please correct me if I'm wrong, Tamar). If things go well his work should be in 8.4. Cheers, - Ben
participants (4)
-
Ben Gamari -
Edward Z. Yang -
Phyx -
Simon Peyton Jones