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.
I've verified that the (small) test suite still passed and had a cursory
look at the code for the bindings. cmark doesn't use any internal Text
modules nor seems to make any specific assumptions about Text's internal
encoding. The interfaces used are Data.Text.Encoding and
Data.Text.Foreign. From the latter, only functions relating to CString
are used which have used UTF-8 encoding already for text < 2.0. (It
stands to reason that cmark may actually benefit from the internal
encoding change in 2.0.)
When building gi-gtk with ghc-9.6.1 and ghc-9.6.2 there are errors
like this:
<no location info>: error:
attempting to use module ‘gi-gtk-3.0.41-DcfU7A0rbDCAyPkJQEwKC:GI.Gtk.Interfaces.Buildable’ (./GI/Gtk/Interfaces/Buildable.hs) which is not loaded
The errors can be avoided by using -j1, which is unfortunate for
gi-gtk because it has 708 modules to build.
The ghc gitlab issue is: https://gitlab.haskell.org/ghc/ghc/-/issues/23392
This applies the Cabal pkgconfig workaround to taffybar and all of its
pkgconfig-using dependencies.
A typical example of the build error looks like this:
Package libpcre2-8 was not found in the pkg-config search path.
The main problem was GHC exceeding the Hydra output limit with profiling
libs on aarch64-linux which made us disable the feature. Nowadays the
limit is 3GB, the GHC output is a bit over 2GB, so easily under the
limit.
aarch64-darwin uses a different codegen backend and was never really
affected by the problem: Its output with profiling enabled is around
1.6GB.
Consequently we can enable profiling for all platforms again, as we have
no output size issues for those we build on Hydra.
Thanks to flokli for helping me track down these up to date numbers.
Some packages cabal-install needed a certain version range (cabal-install-solver
and resolv) have versions incompatible with these in Stackage LTS 21. We can,
however, easily provide the necessary ones.
Additionally, we clean up some old resolv related overrides that are no longer
necessary or we no longer care about (being able to build cabal-install with
GHC 8.6, namely).
For GHC >= 9.0, foldable1-classes-compat is a test only dependency. For GHC < 9.0,
OneTuple also depends on it. It is important to add it to the library's build
depends as well, so it gets propagated properly to builds of packages that depend
on base-compat-batteries (or foldable1-classes-compat will appear as broken to
Cabal).
GHC 9.4 introduced a virtual package for linking against the C++
standard library. Since some packages depend on it when configured with
GHC 9.4 (as hackage2nix does), we need to make sure the attribute exists
or some packages will fail to evaluate. The may still build, even though
there is no shim for lower GHC versions (as far as I know).
