After 120f24202b, GHC_PACKAGE_PATH isn't
set implicitly in installPhase anymore. Instead we achieve the same by
telling the Makefile the exact ghc command line to use.
As a benefit, we can now cleanly separate build and host in this case:
We used to (implicitly) reuse the host package db. Now we can explicitly
request the package db also used for building Setup.hs.
Previously, we would set GHC_PACKAGE_PATH after configure, the reasons
being that
1. Setup.hs configure forbids this from being set since it can make a
build fail that would otherwise succeed (since it influences how
GHC behaves when invoked by Cabal).
2. Setting GHC_PACKAGE_PATH being set is sound in our case, since
we set it precisely to the packages available to Cabal at configure
time, so there should be no room for a mismatch.
3. Some test suites require GHC_PACKAGE_PATH or GHC_ENVIRONMENT to be
set, so they can invoke GHC(i) with build dependencies available.
Cabal >= 3.12 forbids GHC_PACKAGE_PATH from being set after
<https://github.com/haskell/cabal/commit/d6e38041a7c778fadf8f416>.
Setting GHC_ENVIRONMENT would be possible, but is cumbersome without
cabal-install (which has the handy cabal exec command which takes
care of that). Additionally, it is not clear if it'll remain possible
to do that: <https://github.com/haskell/cabal/issues/7792>.
Our solution to Cabal 3.12's change is to be more targeted about setting
GHC_PACKAGE_PATH: We _just_ set it for the actual test suite executable.
This can be achieved by using --test-wrapper which when given is invoked
by Cabal to run the test suite. Here we can set any environment
variables after Cabal has already done its environment checks. As long
as we don't do anything stupid, this should be unproblematic.
Users can also arbitrarily influence what GHC_PACKAGE_PATH will contain
using the NIX_GHC_PACKAGE_PATH_FOR_TEST environment variable. This is
un(der)documented for now, since I want to keep some wiggle room for
changing stuff in the coming weeks. Also it's rarely necessary to
actually touch this variable.
This was achieved using the following command:
sd 'wrapGAppsHook\b' wrapGAppsHook3 (rg -l 'wrapGAppsHook\b')
And then manually reverted the following changes:
- alias in top-level.nix
- function name in wrap-gapps-hook.sh
- comment in postFixup of at-spi2-core
- comment in gtk4
- comment in preFixup of 1password-gui/linux.nix
- comment in postFixup of qgis/unwrapped-ltr.nix and qgis/unwrapped.nix
- comment in postFixup of telegram-desktop
- comment in postFixup of fwupd
- buildCommand of mongodb-compass
- postFixup of xflux-gui
- comment in a patch in kdePackages.kde-gtk-config and plasma5Packages.kde-gtk-config
- description of programs.sway.wrapperFeatures.gtk NixOS option (manual rebuild)
This removes (some of) the special casing for git-annex which we need to
replicate using overrides. As a first step, we recreate an equivalent
set of overrides to the former gitAnnexHook, the only difference being
that we use the default installPhase over a custom implementation.
A big flaw of the current expression (which was shared by the previous
iteration) is that they ignore the testFlags argument. Unfortunately, we
can't do that without changing the generic builder implementation.
After enabling a separate binary output for the `Agda` Haskell package,
the new `bin` output measures ~100MiB, compared to the ~4.5GiB before.
Using it in `agdaWithPackages` reduces the closure size of an Agda
installation from ~5GiB to ~3GiB. The remaining space is taken up
mostly by the GHC backend.
With this change, derivations depending on `haskellPackages.Agda`
directly need to pick the right (binary) output. This concerns in
particular `emacsPackages.agda2-mode`.
The intent of all doCheck = <condition>, where condition is possibly true, is to disable
the tests in a specific case. However, as currently written, this also has the effect of
re-enabling the tests, even if they have been disabled by an override before, e.g. to
mkDerivation.
This also affects the default value given in mkDerivation, which is !isCross. Before this
change, aeson for example, would have been built with tests when cross-compiling, which
was not intended.
The proper way is to set the doCheck = false attribute only conditionally, and otherwise
rely on a previous override or the default value given in mkDerivation.
During configure, postgresql-libpq's Setup.hs will try to execute pg_config to
find libpq. This will not work when cross-compiling, because pg_config was compiled
for the target system, but needs to run on the host.
The "use-pkg-config" flag allows to do this via pkg-config instead, which works
better in those cases.
according https://hydra.nixos.org/build/233205149 the first broken
build of llvm-hs was in 2022-02-18 09:30:43. unpin llvm_9 so LLVM9 can
be removed from nixpkgs
Setup.hs no longer installs the man pages via unix-compat. Instead, this
has to be done manually-ish via the Makefile.
Move passthru to configuration-nix.nix.
