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).
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.
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
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.
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).
Before Cabal >= 3.8, Cabal-syntax did not exist, but there is a dummy
package Cabal-syntax-3.6.0.0 which can be used to prevent the constraint
solver from picking mutually incompatible versions of Cabal and
Cabal-syntax. Since we are now solving flags with Cabal >= 3.8, many
packages have a dependency on Cabal-syntax they did not have before,
requiring us to have a matching attribute in every package set. Using
the dummy package is the safest solution, although it is not required in
every case.
Fixes eval of jailbreak-cabal for GHC < 9.4.
terminfo had a new release on hackage and we only ship the latest
version currently, so every GHC gets the newest version. Whether this is
correct, is another question, occurs to me – we'll have to look into
whether we should fix this at some point.
Since the overrides are practically the same for all but the latest GHC
version, we can move the override into configuration-common.nix and rely
on a few conditionals in the overlay assembly — and end up with less
copying around!
According to the Unicode Standard, you should use U+2019 RIGHT SINGLE
QUOTATION MARK for apostrophes [1]. Before this change, some of the text
in this repo would use U+2018 LEFT SINGLE QUOTATION MARKs instead.
[1]: https://www.unicode.org/versions/Unicode15.0.0/ch06.pdf#G12411
Deprecate haskell.lib{,.compose}.generateOptparseApplicativeCompletion*
in favor of the newly added
haskell.packages.*.generateOptparseApplicativeCompletions (plural!)
which takes into account whether we are cross-compiling or not. If we
are, generating completions is disabled, since we can't execute software
built for a different platform.
The move is necessary, so we can receive the /same/ stdenv as the
package we are overriding in order to accurately check whether we can
execute produced binaries.
Resolves#174040.
Resolves#49648.
This is a dependency of cabal-install and builds by virtue of its
overrideScope. We also want to make sure it builds independently, so
that it doesn't get marked as broken at the very least.
GHC's cross build flavours disable the terminfo package, so it will
never be included if we are cross-compiling – setting it to null thus
breaks all builds depending on the package.
To fix this problem, we use the versioned attribute generated by
hackage2nix, just like we do for xhtml.
Closes#182785.
The xhtml library is only built as part of the GHC build process if GHC
is disabled. This means that no GHC cross compiler has xhtml bundled,
since haddock can't be built if GHC is a cross compiler (see relevant
notes in the GHC nix expressions). This means that all packages
depending on xhtml would currently fail to build when cross-compiled, as
haskellPackages would assume it'd be provided by GHC. This is fixed by
this commit.
pkgsStatic hits this case, so we test compilation of xhtml for these
package sets which will remind us to update the attribute name whenever
its version changes.
Luckily, all build failures where just related to type checking changes
in GHC 9.0 (and maybe base changes?), so we can just use GHC 8.10.7 with
the Stackage version of packages and keep Yi working. I feel like we
dodged a bullet here, as upstream maintenance doesn't seem to be too
proactive these days.
