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.
The aliases, like haskell-language-server-8.10 do not get discovered by the hls-wrapper.
Only `haskell-language-server` and e.g. `haskell-languag-server-8.10.7` work.
I got that wrong when introducing those aliases.
The only big change is required for darwin since GHC 8.10.5 now
runs xattr in the install phase on darwin:
* 11e1dcde0d
* ec451cac39
Unfortunately, it uses the host /usr/bin/xattr by default which is
present in the build due to a lack of sandboxing on darwin. That xattr
version however still requires Python 2.7 whereas Python 3.8 is in PATH
in our build. We solve this by setting the XATTR environment variable.
We can't use python3Packages.xattr since GHC expects Apple's fork of
xattr which provides some extra flags to utilize.
Co-authored-by: Cheng Shao <cheng.shao@tweag.io>
