ghc-8.4.4 requires sphinx < 1.8, otherwise build fails on haddock with:
Extension error: The 'ghc-flag' directive is already registered to domain std
Also fixed evaluation errors in configurations of ghc-8.2.x and ghc-8.4.x.
Closes https://github.com/NixOS/nixpkgs/pull/55703.
If the nix store lives on NFS, `ghc 8.2.1` is unable to build a package
database. This bug was fixed by @bgamari in `ghc 8.2.2` here:
https://ghc.haskell.org/trac/ghc/ticket/13945
This commit upgrades the unpacked bootstrap GHC version, so that we can build
newer versions of GHC even if the store is on NFS.
We keep the latest minor release of each one of the last 3 major releases,
which currently are GHC versions 8.2.2, 8.4.4, and 8.6.1. We also have
ghc-HEAD, but this doesn't count.
Dropping these compilers implied that we have to drop the corresponding
versions of ghcjs, too. We can also drop a shitload of obsolete compiler
patches that newer versions no longer need.
At some point, we can probably simplify the generic builder, too.
The per-version `default.nix`es just fill in default arguments. It is
much more useful to have the `.override` from the inner `callPackage`,
for finer control. Converting the outer `callPackage` to a plain import
makes the inner one the only one, revealing its `.override`.
The compilers themselves can pull them from `bootPkgs`, where they
should always come from anyways. This enforces that, simplifies that
code, and allows use to avoid more `rec { ... }` too.
Fixes mass build failures in these package sets,
due to "unknown pacakge: integer-simple".
Attributes that demonstrate this (see before/after):
* haskell.packages.integer-simple.ghc843.hello
* haskell.packages.integer-simple.ghc802.scientific
The second one is from the NixOS manual, FWIW.
Setting haskell.packageOverrides like so:
haskell = super.haskell // {
packageOverrides = self: super: {
my-package = ...;
my-other-package = ...;
};
};
causes all compiler-specific package sets to be overridden with those
overrides.
None of these old compilers are used anywhere in Nixpkgs, and keeping those
builds working in the face of regular updates of GCC, binutils, and whatnot is
too much effort for no obvious benefit.
