| 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 |
| 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 |
| emily | well, then just import one? :) | 13:54:05 |
| emily | (mixing a compiler from one version with packages from another isn't a great idea anyway) | 13:54:17 |
| bake.monorail | stuck in 2021 forever | 13:54:18 |
| emily | well, yes… if the premise is using a compiler from 2021, that's the life you've chosen :) | 13:54:38 |
| bake.monorail | eh, it's more complicated than that, but OK | 13:54:57 |
| bake.monorail | more on practical things, I assume you're somehow involved in maintaing compilers, what would you think about making compilers more externally overridable (I'm thinking about making versions an argument of pkgs/development/compilers/gcc/all.nix. I guess it wouldn't be too bad, what do think? | 13:56:57 |
| bake.monorail | * more on practical things, I assume you're somehow involved in maintaing compilers, what would you think about making compilers more externally overridable (I'm thinking about making versions an argument of pkgs/development/compilers/gcc/all.nix. I guess it wouldn't be too bad, what do you think? | 13:57:01 |
| bake.monorail | * more on practical things, I assume you're somehow involved in maintaing compilers, what would you think about making compilers more externally overridable. I'm thinking about making versions an argument of pkgs/development/compilers/gcc/all.nix. I guess it wouldn't be too bad, what do you think? | 13:57:16 |
| emily | wouldn't really do much good | 14:01:13 |
