Fix instances of tool dependencies coming from `self` or `pkgs`
instead of `self.buildHaskellPackages` or `pkgs.buildPackages`
respectively. This makes sure cross-evaluation and -compilation will
work although their may still be more kinks to work out (or cases I
missed). This change was mostly created by searching for `[tTool]` and
`\${` in the respective files.
Note that this has intentionally not been for test tool dependencies:
Like in `stdenv.mkDerivation` we need to view tests as being executed
on the *host platform* which is why we can't run tests while cross
compiling anyways. In practice this is not an important distinction,
though: `pkgs.buildPackages` and `pkgs` are almost identical in the
native case.
Resolves#127232.
For native compilation, we can just add the intermediary build
directory to `PATH` which allows the test suite to be preprocessed by
tasty-discover itself.
When cross-compiling, `doCheck` will be false anyways and this won't
matter (fingers crossed!).
If we are cross compiling we can't and don't run the tests since they
wouldn't be able to be executed on the host platform.
While native compiling, we need to avoid an infinite recursion.
stackage LTS 18 luckily updated haskell-gi and related libraries to
0.25, so we can remove a lot of overrides. I also unrestricted some of
them in configuration-hackage2nix/main.yml and removed the overrides
updating them in configuration-common.nix (I guess the person doing
the upgrades thought those libraries were also in stackage).
Add assert which will fail when the overrides can be removed. Upstream
has patched the bounds, but hasn't made a new release nor a hackage
revision so far.
Every flag the generic builder receives via `testFlags` is passed via
`--test-option` [1] to `Setup.hs` which in turn passes them to the
underlying test suite binary. These wrapped options are added to
`checkFlagsArray` in `checkPhase`. This needs to be done in bash since
without structuredAttrs in nixpkgs so far, Nix arrays aren't properly
translated into bash arrays, so we'd have all sorts of quoting issues
when spaces are involved.
Re-using `checkFlags` and `checkFlagsArray` from standard stdenv
setup.sh also results in an additional feature: Using `overrideAttrs`
`checkFlags` and `checkFlagsArray` can additionally be overridden,
which allows passing extra flags to `Setup.hs` whithout being wrapped
with `--test-option`.
[1]: See also https://cabal.readthedocs.io/en/3.4/setup-commands.html?highlight=test-option#cmdoption-runhaskell-Setup.hs-test-test-option
According to the cabal-install man page this also allows passing
special variables which are substituted for other values
depending on context.
While diagrams-lib 1.4.4 doesn't per se require us to update any
diagrams lib to 1.5.0 it would require monoid-extras 0.6 which would
force us to update diagrams-core to 1.5.0, thus breaking
haskellPackages.diagrams.
Since we can just keep the patch we fetch and downgrade to 1.4.3, we
can continue sitting out the slow update cycle of the diagrams universe.
This reverts commit 52d69816b0.
Unfortunately there is no way to update to monoid-extras 0.6 yet without
marking some packages as broken. The issue is that not all diagrams*
packages have had an update adding support for GHC 9.x yet (which would
also include monoid-extras 0.6 support). The only alternative to pinning
diagrams* and monoid-extras would be to have mismatched versions between
them which always causes issues with haskellPackages.diagrams.
Note that this commit re-introduces some build failures which are to be
fixed in a follow-up commit.
Seems like the monoid-extras situation wasn't as bad as I thought and
some new releases in the meantime make every diagrams package we had
working previously work again.
* haskellPackages.monoid-extras: 0.5.1 -> 0.6
* haskellPackages.diagrams-lib: remove now unnecessary patch
* haskellPackages.namespace: jailbreak to build with new monoid-extras
