ghc8107Binary should probably be dropped, too – I did not bother verifying my bootstrap hack with 8.10.7, so this will presumably get broken for lack of NCG or working LLVM, and anyway it only covers bootstrap of versions that are due for removal. Out of scope for this PR, of course, and maybe the fix is just… drop ghc8107 and ghc928 in general.

(I doubt anyone is doing native builds for AArch32 these days anyway. It was broken on the Nix side for a while and nobody noticed.)

I did not bother verifying my bootstrap hack with 8.10.7, so this will presumably get broken for lack of NCG or working LLVM, and anyway it only covers bootstrap of versions that are due for removal.

I think 8.10.7 can only be dropped if we drop AArch32 support entirely.

(I doubt anyone is doing native builds for AArch32 these days anyway. It was broken on the Nix side for a while and nobody noticed.)

Yeah, that's the part I have no idea of. If we all agree that we can drop native AArch32 support, then we can drop 8.10.7 bindist and 9.2.8 from source, too.

Okay, I guess there is a long bootstrap chain back to the existing AArch32 bindist.

I am sceptical that there is AArch32 hardware that can viably compile modern GHCs. I think that if people want to do that, the cross bindist approach is the way to go. I expect that the 8.10 bindist would work with subopt and could therefore be used to keep this long bootstrap chain working, but am reluctant to spend time on validating that given that even cross‐compiling to AArch32 is flaky in Nixpkgs and that using it natively has been impossible at various points in recent history. From my previous conversations with @sternenseemann I don’t remember this coming up as a concern for dropping 8.10, at least.

I can happily propose a PR to drop ghc8107Binary along with the whole isAarch32 chain - but only once this one here is merged, since it touches all the same lines.

Seems sensible to me. Might as well just drop 8.10 entirely? Which should probably be done after dropping the 9.0 source build, as there’s no point running a build to verify a bootstrap chain for a compiler due for removal anyway.

This is so hard to keep track of, you guys should discover the joys of PRs that delete > 6,000 lines all at once.

Well, a lot of these things only surface while we're already discussing things. I lack the overview of what can all be dropped, so I'm trying to slice off pieces 1-by-1 to make progress overall.

I basically just start hitting the backspace key and only open a PR once it wears out and I have to go out and buy a new one :)

Let's do it bit by bit.

armv7l and ppc64le are going to be the victims of this.

we can drop 8.10.7 bindist and 9.2.8 from source, too

Even with subopt, there is not really a way to get 9.2 with a recent enough LLVM version.

Hm, why is that? I assume the LLVM patches could be extended back, and subopt should work for the bootstrap. But maybe I’m missing something (significant changes in the backend around that time?).

OTOH I don’t think it’s worthwhile, compared to doing the cross bindist thing.