Rather than hardcoding the path to GHC's libdir which may change, use
`ghc --print-libdir` in wrappers.
Another option would be to expose mkGhcLibdir from generic-builder.nix.
Also add a test for mueval.
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
Bootsrapping with 9.6 doesn't work with 9.8.2 upstream due to erroneous
bounds on Cabal (<https://gitlab.haskell.org/ghc/ghc/-/issues/24100>)
which was planned to be addressed in 9.8.2, but apparently hasn't been,
so we need to extend the range for the workaround patch.
That GHC version should be allowed due to bootstrapping support windows
GHC HQ promises, but isn't possible in practice due to an overly strict
constraint on Cabal in hadrian.
This introduces a list of `supportedFormatters` that are the ones that
should be compiled into hls. Removes a nontrivial amount of transitive
dependencies if only one formatter is used in a project.
This saves just enough space on aarch64-linux so that the hadrian built
GHCs are under the 3GB Hydra output limit:
| compiler | before | after | Δ |
|----------|------------|------------|------------|
| ghc962 | 3241234736 | 2810740560 | -430494176 |
| ghcHEAD | 3341288328 | 2902760872 | -438527456 |
The total output size can be calculated using (don't forget to use
aarch64-linux):
```
nix-build -A <compiler> | xargs nix path-info -s | awk '{ s += $2 }; END { print s }'
```
ihaskell-display was changed recently to no longer use the
switchToTmpDir IO action. This change also affected ihaskell-diagrams,
but only a new version of ihaskell-display has been released.
ihakell-diagrams' latest hackage version thus depends on a removed IO
action from ihaskell-display and can't be compiled.
Initial port of our GHC Nix expressions to the new hadrian build system,
as it has become required after 9.4. Unfortunately there are some
regressions affecting us, namely the inability to install a GHC
cross-compiler at the moment (see issue linked in relevant error
message). This means that a lot of specific configuration snippets for
cross-platforms and static compilation have been ported from make
speculatively, as we are unable to test them for the moment.
If we are linking dynamically, it's practically no use removing
references, as we depend on GHC either way via linking.
I've also elected to keep the references to the data outputs in all
cases — they are a bit arcane (there's no easy way to tell they
definitely are not necessary) and don't contribute too much to the
overall closure size.
haskell-language-server will now default to building a shared
executable, as upstream does, complete with a huge closure. By passing
{ dynamic = false; } via override, it is still possible to build a
"statically linked" variant of HLS, as it used to be.
Note: Before this change HLS would fail to compile on aarch64.
