ghc-lib >= 9.4 won't compile with GHC 8.10 anymore, so we'll use the
newest version that still works (we used ghc-lib == 9.2.* with Stackage
LTS 20 as well).
Unfortunately hspec 2.7 no longer compiles with GHC >= 9.4, so we hide
it in the Hydra jobset. It is preserved nonetheless, as it is used by
ghcjs (which still uses hspec 2.7 and GHC 8.10.7).
weeder has no actively maintained support for older GHC versions, so we
need to partially restore historic install-plans when it is affected by
breaking changes in other libraries than GHC.
Since we can't reliably (or easily at least) tell what Cabal version is
used, we should allow overriding whether to propagate or not, although
GHC >= 9.3 is correct in most cases.
The main idea is to limit the amount of flags passed to Setup.hs as well
as, consequently, linkers and C compilers. E.g. in the case of
gi-javascriptcore, the default behavior causes the argv limit to be
exceeded.
Just getting the length of allPkgconfigDepends now may require a quite
expensive and involved function to be execute, so it should be put off
as long as possible. We can achieve this by moving the assert for
pkg-config being available next to its inclusion in nativeBuildInputs.
This solves the infinite recursion triggered by hercules-ci-cnix-store.
This change essentially amounts to inlining
__CabalEagerPkgConfigWorkaround into haskellPackages.mkDerivation and
applying it automatically for the affected GHC versions. This is a bit
overeager, but the best automatic solution we can come up with for now.
Consequently, we don't need __CabalEagerPkgConfigWorkaround in nixpkgs
anymore nor downstream at least for “standard” haskellPackages builds.
__CabalEagerPkgConfigWorkaround is preserved for now since it is still
necessary if using GHC < 9.4 with Cabal >= 3.10 or cabal-install >= 3.10.
The one thing that may or may not be negatively affected by this change
is ghcWithPackages. I doubt this is a problem in practice though, since
it didn't provide pkg-config in the first place. passthru.env and
shellFor do and work correctly since they rely on mkDerivation.
This removes 'ldgallery' from nixpkgs.
It remains available through the Nix Flake provided by ldgallery.
The package of its "compiler" part was already marked as broken due to
dependencies having gone out of sync with the rest of the Haskell
packages.
The package of its "viewer" part also got out of sync due to changes
in JS dependency manager.
Since 500b36d057, there is a more recent
version of skylighting and skylighting-core available than Stackage LTS
contains. We'll have to manually provide matching versions for pandoc
3.1.6 again.
ghc-source-gen being broken is the norm now, as it only supports
GHC < 9.4. To keep tabs on it still (it is required for HLS some of the
time), we add it to release-haskell.nix.
The main motivation for this is that the latest versions of hspec-core
and hspec-expectations got out of sync due to an unlucky timing on the
hackage snapshot update. As a consequence, we weren't able to build
cabal-install in some package sets. Additionally, this brings a version
of futhark that can be built with the lsp version we ship.
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh
and maintainers/scripts/haskell/regenerate-hackage-packages.nix.
Additional changes:
* Adapt to new xhtml version (still doesn't match the version normally
shipped by the respective GHC as a core library).
* Adapt to new versions of hspec* and pandoc
all-cabal-hashes: 2023-06-28T16:36:39Z -> 2023-07-19T20:56:38Z
This commit has been generated by
* maintainers/scripts/haskell/update-hackage.sh
* maintainers/scripts/haskell/update-stackage.sh
* maintainers/scripts/haskell/regenerate-hackage-packages.sh
Additionally, the following manual changes are included:
* Delete now obsolete overrides for
- base-compat, base-compat-batteries (new release in stackage)
- cmark (new release in stackage)
- skylighting (newer release than 0.13.3 in stackage)
- optics (new release in stackage)
* Adjust to new versions for
- hspec, hspec-core, hspec-discover, hspec-expectations
- fourmolu
- pandoc
- doctest
!fixup stackage
Building base-compat-batteries-0.12.2 against OneTuple == 0.4.* as we do
for GHC < 9.0 could lead to confusing results for users of
Data.Tuple.Compat. Thankfully upstream has provided a solution they are
satisfied with and released it as 0.12.3 to which we preemptively
upgrade (but it should enter Stackage LTS 21 soon enough)
See https://github.com/haskell-compat/base-compat/pull/92.
This reverts commit 54ebdad42d.
