This is a left over to do from #308776. Rebasing existing PR (prior
to #308776) would need to be rebased on a change before the commit
included in this PR.
The common expression is a little messy to avoid rebuilds. It can be
cleaned up in a second step.
`9.4.8.fixme.nix` is used temporarily so that git's rename detection
gets where common-make-native-bignum.nix is coming from.
8.10.7 keeps its expression since it uses integer-simple which changes
the expression's interface. This is unfortunately very annoying to
reflect in a common expression.
Unfortunately, we are running into trouble linking dependencies of
hadrian against the libraries of the clock package with 9.6.3 and
9.6.4 _bindists_. My current suspiscion is that this is caused by
some kind of discrepancy between the toolchain used by GHC upstream
and us that persists from the configure step used when building the
bindist. The problem seems to be somewhat localized to hsc2hs (hence
clock is an issue), with GHC 9.6.4 bindists even passing a flag to
ld that is not supported by our version of cctools.
The problem is not fully diagnosed, so take the speculation above
with a grain of salt.
As a workaround, we can use the source built GHC 9.6 which is, of
course, configured with our toolchain in the environment.
Bootsrapping with 9.6 doesn't work with 9.8.2 upstream due to erroneous
bounds on Cabal (<https://gitlab.haskell.org/ghc/ghc/-/issues/24100>)
which was planned to be addressed in 9.8.2, but apparently hasn't been,
so we need to extend the range for the workaround patch.
native-bignum has become the norm, so let's convert it to an exclude
rather than an include list. This way it's no longer possible to forget
to add a newly packaged GHC to the include list.
Best reviewed by viewing
diff -u pkgs/development/compilers/ghc/9.{2.4,6.3}-binary.nix
main change are that we drop the `isHadrian` mechanism, since all
bindists are produced by hadrian and alpine bindists are also available
dynamically linked now.
https://www.stackage.org/ lists the latest LTS snapshot for any GHC
version which, on the flipside, lets us discover which versions don't
have a corresponding LTS snapshot. There is really no reason to keep
around GHCs that only appeared in some nightly snapshot way back.
haskell.compiler.ghc924: remove at 9.2.4
haskell.compiler.ghc942: remove at 9.4.2
haskell.compiler.ghc943: remove at 9.4.3
haskell.compiler.ghc944: remove at 9.4.4
haskell.compiler.ghc962: remove at 9.6.2
We want to remove llvmPackages_6, but it is the only version GHC 8.6.5
supports. Luckily, we actually don't need LLVM in any case, since all
X86 architectures have native codegen for Darwin and Linux, as well as
POWER for Linux. Consequently, we can just pass `null` and add an extra
assert to make this more transparent to future tinkerers.
There won't be any new integer-simple compilers and they are already in
the minority, so converting the mechanism to an include list is much
better. Maybe native-bignum should now become an exclude list
additionally?
Verified that nix-env -qaP -A haskell.compiler output stays identical.
haskell.compiler.ghc8102BinaryMinimal: remove at 8.10.2
haskell.compiler.ghc8107BinaryMinimal: remove at 8.10.7
haskell.compiler.ghc924BinaryMinimal: remove at 9.2.4
On aarch64-linux the binary GHCs take up about 2.6GB (which compresses
pretty well on zfs as it turns out), so they are below the output limit
of Hydra. This allows us to drop the special casing of aarch platforms
in haskell-packages.nix. While we're at it, drop the minimal variants so
we don't unnecessarily build variants of the binary GHCs.
This should make overriding the precisely versioned set also influence
the default aliases. When overriding the aliases, still only the aliases
would be changed.
GHC HEAD is a pre basically pre GHC 9.8 (or rather 9.7 something).
Let's name the configuration like the upcoming release, so we can use it
immediately when the new release comes out. Instead of keeping the HEAD
configuration like we used to, we'd create a new (empty) one.
