| 18 Dec 2025 |
 emily | (as the person who dropped the most recent batch of GCCs and LLVMs:) yes, it is a meaningful burden on LLVM and GCC maintenance | 13:38:48 |
 matthewcroughan | The fact that it's in a file means it's not private, you could just versions = import ./pkgs.path + "pkgs/development/compilers/gcc/versions.nix"; no? | 13:39:19 |
| matthewcroughan | * The fact that it's in a file means it's not private, you could just versions = (import ./pkgs.path + "pkgs/development/compilers/gcc/versions.nix"); no? | 13:39:34 |
 bake.monorail | even without taking cc-wrapper into account? | 13:39:41 |
| matthewcroughan | * The fact that it's in a file means it's not private, you could just versions = (import ./pkgs.path + "/pkgs/development/compilers/gcc/versions.nix"); no? | 13:39:44 |
| emily | yes | 13:39:45 |
| emily | e.g.
- having to non-trivially patch old compilers to keep working with newer versions of everything else (e.g. newer Darwin SDK incompatibilites with with older compiler versions)
- having to backport patches from new compilers to old compilers to work around bugs
| 13:40:11 |
| emily | often in tandem | 13:40:14 |
| 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 |
| emily | it is maintenance burden however you slice it, and I can attest that it was a very frustrating way to spend our limited maintenance resources for very little benefit | 13:44:37 |
| bake.monorail | fair fair | 13:45:51 |
| emily | I considered https://github.com/NixOS/nixpkgs/pull/440273, https://github.com/NixOS/nixpkgs/pull/435019, and all the PRs linked from them to be worth the effort to do compared to what carrying many EOL compilers has been like, despite them taking like 2 months in total | 13:46:00 |
