| 18 Dec 2025 |
 emily | also, dealing with divergence in build systems over time | 13:40:25 |
| emily | all of these add non-trivial complexity to the compiler derivations and backporting work for patches | 13:40:38 |
| emily | having old compilers available also means that things will inevitably use them, so e.g. LLVM 12 was load-bearing for way too long on AArch64 because of GHC | 13:41:11 |
| emily | which exacerbated the amount of work that had to be done to keep it working with manual backports | 13:41:27 |
| emily | another example of the former is that we have had multiple cases where old compilers would not build with new compilers | 13:41:56 |
| emily | due to them getting more strict | 13:41:59 |
| emily | so since everything roots to a new compiler in the stdenv bootstrap, we had to backport patches to fix that as well | 13:42:18 |
 bake.monorail | I can understand the others, but in my experience this is not something tragic to do and it's worthwhile, at least with LLVM. | 13:43:45 |
| bake.monorail | but yeah, I was thinking of making a PR to enable manually overriding compiler versions (see the versions.nix thing above), letting whoever hacks with handle it, but at least in a way that does not require forking. | 13:44:32 |
