| 18 Dec 2025 |
 matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | like providing toolchains as overlays in nix works well | 13:37:04 |
 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 @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | * 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 @ 39c3 (DECT 94667 or 97340 or 67192) | * 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 |
| emily | (you can see the thousands of lines deleted from the compiler derivations in those and the vastly reduced conditional complexity of the derivations, but can't see the burden over time of when stuff breaks) | 13:46:35 |
 Artturin | In reply to @bake.monorail:matrix.org
I'm rather sad that end-of-life'd compilers are dropped from nixpkgs. old compilers are sometimes very useful. is it such a large burden to keep them alive? Luckily it's easy to use a old nixpkgs revision | 13:46:34 |
| bake.monorail | yeah that's a great thing about nix but also not ideal. | 13:47:50 |
| emily | (previously https://github.com/NixOS/nixpkgs/pull/357657, https://github.com/NixOS/nixpkgs/pull/341714) | 13:48:00 |
| bake.monorail | thanks, I will take a look, that's what I was looking for | 13:49:00 |
| emily | in some ways it is ideal: you get a less patched compiler that is closer to the old version you actually want, with versions of its dependencies closer to what it actually expected at the time | 13:52:37 |
| emily | retro X tends to go a lot better with retro Y | 13:52:44 |
| emily | (which is why another side effect of packaging old versions is that you end up with the exponential cost of carrying old versions of entire dependency trees all the way) | 13:53:06 |
| bake.monorail | yeah but importing nixpkgs multiple times is Sad™ | 13:53:37 |
