haskell-generic-builder: disable library-for-ghci by default #59297
Conversation
This commit disables the library-for-ghci flag passed to `Setup configure` in the Haskell generic-builder.nix file. This stops the HSfoo.o file from being built. Building this HSfoo.o file caused doctest to take an extremely long time to load dependencies when running. This is a follow-up from NixOS#58743.
|
Locally, I tried building a bunch of Haskell packages with the change from this PR. Everything seems to build and run fine. |
|
I think this might be linked to this GHC ticket: https://gitlab.haskell.org/ghc/ghc/issues/15524#note_193060 Just worth keeping on the radar that we should check whether we should revert this if that ticket gets fixed. |
|
@michaelpj Thanks for the link to the GHC issue! |
|
With this patch applied, every single Let's hope that this was caused by some freak accident / issue on Hydra itself. I'll try restarting the builds ASAP, but this does look a little strange. |
|
@peti, hmm, that's strange. I've tried it many times locally on both NixOS and Debian (with nix) and never run into a problem with building GHC. Do you have a link to the hydra failure? I'm not very familiar with how to use Hydra, but after poking around a little bit, it looks like this might be the evaluation you restarted: https://hydra.nixos.org/eval/1513940 If I go to the "Queued jobs" tab and search for I guess another thing we could do is ask ofborg to rebuild something like It looks like ghc822 has succeeded: https://hydra.nixos.org/build/92045197 But ghc844 is hanging at the very end? https://hydra.nixos.org/build/92045468 ghc822 only took about 2 hours to build, but ghc844 has taken over 5 hours so far. It looks like ghc844 is hanging at the very end, right after it is checking for references to Maybe this is indicative of hydra errors? The logs for the ghc822 build basically end in the same way, but this appears to succeed: |
|
I can confirm that this issue is what caused https://gitlab.haskell.org/ghc/ghc/issues/15524 I also managed to build GHC with this flag patched away. Thank you @michaelpj and @cdepillabout for finding this issue and pointing me to it. |
|
The compiler builds don't seem to end. 20h and counting. :-( I have opened NixOS/hydra#650. This looks like an issue with Hydra. Maybe it got stuck while copying the build products into the cache. |
|
@peti It looks like ghc822 and ghc864 have succeeded: ghc822: https://hydra.nixos.org/build/92045197 Hopefully we can get ghc844 (and, well, ghc865) succeeding soon too. Although now that ghc864 has succeeded, hopefully a bunch of the Haskell packages will start succeeding now too. |
|
The strange thing is that I can't reproduce this problem without nix so perhaps it's the interaction of this flag with another flag which causes the issue. I am trying various incantations of |
|
Indeed, I can now reproduce the problem without nix at all. You also need |
|
If anyone is interested by investigation and minimal reproduction are here |
|
OK, the new compiler built successfully by now and I tested it too. Everything works as expected. The |
|
@peti Thanks a lot for your help with this one! |
This commit disables the library-for-ghci flag passed to
Setup configurein the Haskell generic-builder.nix file.This stops HSfoo.o files from being built. Building HSfoo.o files cause doctest to take an extremely long time to load dependencies when running.
This is a follow-up from #58743. There is more explanation on that PR.
Motivation for this change
It is debatable as to whether or not we should make this change.
The reasons in favor of making this change:
stackandcabaluse--disable-library-for-ghciby default. It makes sense that nixpkgs would follow this.library-for-ghcireduces the build times very slightly. The resulting output takes up slightly less disk space. (I don't think this is a particularly compelling reason though.)The reasons against making this change:
--enable-library-for-ghcibeing used? Maybe disabling it would break their build/workflow somehow? I have done a bunch of searching around this issue trying to figure out what is going on here, and I haven't found any reference to anyone specifically enabling or disablinglibrary-for-ghci, so I would doubt anyone is actively depending on it (although there is a possibility).library-for-ghcicauses packages to be loaded into GHCi slightly quicker than when it is disabled: haskell-generic-builder: Add option to disable library-for-ghci #58743 (comment). However, in the case ofdoctest(which loads packages uses the GHCi API), this seems to not be the case. I don't know what is going on here.My personal opinion is that we should merge this PR and disable
library-for-ghciby default. I think it is more important that commonly used tools likedoctestwork well, than having libraries (sometimes?) load slightly quicker in GHCi.At some point in the future, I imagine it would be best if we could figure out what's going on with doctest, and whether the bug lies in our nix stuff, doctest, Cabal, GHC, etc.
Pinging @peti.
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nix-review --run "nix-review wip"./result/bin/)nix path-info -Sbefore and after)