This closes #79441.
ghcWithPackages is using `ghc-pkg recache` to build its package
database. By doing so, it overrides the `package.cache[.lock]` files.
Details are unclear, but GHC 8.10 changed a bit the behavior.
Previously, it was unconditionally replacing the files by new ones. Now
it tries to open (for modification) the files. These files are symlinks
to another nix derivation, which is hence read-only.
This commit removes the files before running `ghc-pkg recache`, hence it
will just write the new files.
Tested with `haskellPackages.ghcWithPackages` (i.e. GHC 8.8) and
`haskell.packages.ghc8101.ghcWithPackages` (i.e GHC 8.10) with the
following nix file, at the root of the nixpkgs repository:
```
with import ./. {
overlays = [
(
self: super: {
haskellPackages = super.haskell.packages.ghc8101.override {
overrides = selfh: superh: {
th-lift-instances = super.haskell.lib.doJailbreak superh.th-lift-instances;
th-expand-syns = super.haskell.lib.doJailbreak superh.th-expand-syns;
th-reify-many = super.haskell.lib.doJailbreak superh.th-reify-many;
th-orphans = super.haskell.lib.doJailbreak superh.th-orphans;
haskell-src-meta = super.haskell.lib.doJailbreak superh.haskell-src-meta;
};
};
}
)
];
};
haskellPackages.ghcWithPackages(p:[p.PyF])
```
This will test with GHC 8.10. Comment out the `overlays` to test with
GHC 8.8.
The Sierra linker added a limit on the number of paths that any one
dynamic library (`*.dylib`) can reference. This causes problems when
a Haskell library has many immediate dependencies (#22810).
We follow a similar fix as GHC/Cabal/Stack: for each derivation,
create a new directory with symlinks to all the dylibs of its immediate
dependencies, and patch its package DB to reference that directory
using the new `dynamic-library-dirs` field.
Note that this change is a no-op for older versions of GHC, i.e., they will
continue to fail on some packages as before.
Also note that this change causes the bootstrapped versions of GHC to be
recompiled, since they depend on `hscolour` which is built by
`generic-builder.nix`.
Tested by building the `stack` binary as described in #22810.
This also:
1 Builds Setup.hs with ghcjs, which (among other things) defines
__GHCJS__ and ghcjs_HOST_OS during pre-processing.
2 Fixes ghc-paths to point at ghcjs and use NIX_GHCJS_* env-vars.
3 Boots ghcjs into $prefix/lib/$compiler.
postBuild can be used to execute user-specific commands on the generated $out
environment before finalizing the build. For example, this hook can be used to
generate appropriate 'makeWrapper' script for binaries contained in the
environment.
The builder creates a temporary package.conf.d database in $TMP that
contains everything required to build the current package (i.e. the
transitive closure of the package's propagated build inputs). These
files are no longer installed, however, we just install the package.conf
file for the package we're actually building. This means that
package.conf.d directory in $out won't have collisions anymore, which
simplifies the with-packages-wrapper.nix a bit.
Furthermore, export "name" and "version" attributes that match those of the
underlying compiler. These changes make a ghcWithPackages-generated wrapper
look exactly like a normal GHC derivation and it can be used anywhere in
Nixpkgs where a normal GHC would be used.
