The approach taken to add this package was to port over the definitions
currently existing for HEAD, and making the necessesary changes to get
this building.
The Haskell package set associated with this compiler doesn't yet
guarantee that all or most of the packages successfully build with this
new compiler, but that will improve over time after this GHC 8.2.1
is officially released and the ecosystem catches up.
By default, `ghcjs` haddocks are precluded from being built. I see no reason to disallow building haddocks on projects built with `ghc` and `ghcjs` (someone can correct me here). `HaLVM` currently does not support `haddock` since it's a Stage 1 `GHC`. https://github.com/GaloisInc/HaLVM/blob/master/src/misc/build.mk.in#L20
Currently, building `haddocks` for `ghcjs` projects requires altering the derivation, which doesn't allow users to take advantage of the cache. This change will relieve that.
This change is effectively a no-op to nixpkgs. However, it gives users
the flexibility to create and maintain their own package sets per
project, while benefiting from nix's Haskell configurations.
I would make immediate use of this change in stack2nix, a project that
generates nix expressions for all the dependencies of a given Haskell
project. @domenkozar is familiar with the motivations and helped
refine this change
As noted in #25595, a change introduced in 4b77d425aa causes an
explosion of inodes due to the constructions of many, many `ghcEnv`
symlink forests. This commit undoes that change.
To discuss reworking the support for GHCJS plugins, please see: #26192Fixes#25595
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.
