| 18 Dec 2025 |
 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 |
| emily | the GCC derivations have pretty extensive version conditionals | 14:01:20 |
| emily | the LLVM ones are closer to being something you can reasonably override versions out-of-tree but still not really there | 14:01:35 |
| emily | I suggest just maintaining a fork of gcc/ | 14:01:45 |
| emily | it will be less painful than a nest of hacky overrideAttrs | 14:02:00 |
| emily | (I also suggest putting this effort into making a newer GCC work instead) | 14:02:15 |
| bake.monorail | OK, thanks for the feedback | 14:02:29 |
 rosssmyth | Something I was considering yesterday:
Currently we have gcc-arm-embedded, which is a pre-built GCC distribution. It has a manifest with all the configure flags. How hard is it to add a new version of GCC? I took a little look and there's a lot of machinery all over the place in the GCC directory. Maybe easier to use the NG package set?
| 15:22:17 |
 K900 | Add a new version of GCC that does what? | 15:23:37 |
| K900 | Builds a proper nixpkgs stdenv/ | 15:23:50 |
