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 https://github.com/NixOS/nixpkgs/pull/58743.
- The previous build of Cryptol was broken on GHC 8.6.x, which is now the
new default. That's been fixed with a few upstream patches that will come
up whenever the next release happens.
- There was also a build failure on base-compat, fixed by jailbreaking.
- The previous setup had all-packages.nix creating a new derivation
solely for the purpose of wrapping the Z3 binary. This has been removed:
the wrapper is still added but during the Haskell build itself, so that
all Haskell dependent packages can use the cryptol interpreters too.
- In its place, we use justStaticExecutables, so people using nix-env
and Cryptol users who *don't* need haskell dependencies can get much
smaller closures. Obviously this still implies a second build, but
this build is much more useful than one that merely adds a shell
script to a package that's relatively expensive to compile...
Signed-off-by: Austin Seipp <aseipp@pobox.com>
In order to build the package databases that we will use when compiling
a Haskell package, we iterate over the relevant dependencies, and if
they contain a package db, we copy its contents over.
So far so good, except when one of those dependencies is GHC. This
doesn't happen ordinarily, but it will happen when we construct the
package database for compiling `Setup.hs`. This is compiled for the
build architecture, so we get the build deps, including both the native
and the cross GHC (if there is one).
In this case, we end up copying the packages from the GHC's package
database. This is at best unnecessary, since we will get those packages
from the GHC when we compile with it.
At worst, however, this is semantically questionable. We can end up
having multiple copies of e.g. Cabal with the same version, but
(potentially) different contents. At the moment, GHC will expose one of
these at semi-random depending on which one it looks at "first".
However, there is a MR open [in
GHC](https://gitlab.haskell.org/ghc/ghc/merge_requests/545) which as a
side effect will instead expose both, leading to ambiguous module
warnings (which is not unreasonable, since it *is* ambiguous).
So what can we do about it? The simplest solution is just to not copy
the package databases from GHC. GHC is special in this regard, so I
think it's okay to treat it specially.
This PR should have no effect on anything now, but will prevent any
breakage when/if the GHC patch lands.
Closes https://github.com/NixOS/nixpkgs/pull/57706.
