search

snowleopard / hadrian

Hadrian: a new build system for the Glasgow Haskell Compiler. Now merged into the GHC tree!
https://gitlab.haskell.org/ghc/ghc/tree/master/hadrian
MIT License
208 stars 37 forks source link

fix management of nontrivial dynamic flavours of libHSrts #698

Closed alpmestan closed 5 years ago

alpmestan commented 5 years ago

Where non trivial means e.g "threaded dynamic", i.e not just "dynamic".

This requires a Cabal patch: https://github.com/haskell/cabal/pull/5606 and a GHC patch that bumps Cabal and also adds:

diff --git a/rts/rts.cabal.in b/rts/rts.cabal.in
index 76fd353134..9c95fbb342 100644
--- a/rts/rts.cabal.in
+++ b/rts/rts.cabal.in
@@ -39,6 +39,8 @@ flag debug
   default: False
 flag logging
   default: False
+flag dynamic
+  default: False

 library
     -- rts is a wired in package and
@@ -65,8 +67,14 @@ library
         extra-library-flavours: _debug_p _thr_debug_p
     if flag(debug)
       extra-library-flavours: _debug _thr_debug
+      if flag(dynamic)
+        extra-dynamic-library-flavours: _debug _thr_debug
     if flag(logging)
       extra-library-flavours: _l _thr_l
+      if flag(dynamic)
+        extra-dynamic-library-flavours: _l _thr_l
+    if flag(dynamic)
+      extra-dynamic-library-flavours: _thr

     exposed: True
     exposed-modules:

I will submit it once the Cabal patch is merged. Until then, I thought it would be a good idea to have this PR ready. As reported in #695 I can build & install all the dynamic RTS flavours I want with all those patches. This effectively fixes #695.

snowleopard commented 5 years ago

Thanks @alpmestan! I'll give it a proper review in a couple of days. (Currently overwhelmed with teaching and other university commitments at the start of the year, plus upcoming Haskell eXchange.)

alpmestan commented 5 years ago

Note that after rebasing against latest hadrian & ghc, my Cabal patch doesn't work anymore. The source of the problem has not been identified yet, but the symptom is very simple to describe.

1/ hadrian still builds all the fancy flavours that we want, it puts them under /stage1/rts/build/ 2/ when we Hadrian.Haskell.Cabal.configurePackage, we do get all 4 flags (profiling, logging, dynamic, debug) from the Cabal Flags builder and pass that to Cabal 3/ much further down the road, when comes the time to install the static and dynamic libraries for libHSrts, it looks as if extra-dynamic-library-flavours is empty, except that with the 4 flags that we do pass when configuring, we should get the entire menu of dynamic flavours listed in there! So my Cabal patch ends up installing just the "vanilla shared" RTS library...

@DavidEichmann (who recently started giving us a helping hand on the hadrian testsuite front and hadrian/ghc in general) and I are looking into this.

snowleopard commented 5 years ago

Many thanks @alpmestan and @DavidEichmann!

bgamari commented 5 years ago

What happened to this?

alpmestan commented 5 years ago

@bgamari A lot :-) See https://ghc.haskell.org/trac/ghc/ticket/15837 which sums everything up. In particular, the cabal PR I made got merged yesteday, so we're finally going to be able to proceed with the rest of the plan outlined at #15837.

snowleopard commented 5 years ago

@alpmestan Thanks! I guess we should close this PR here then?

alpmestan commented 5 years ago

Yes we can, the ticket I mentionned above "took over" :-)