| 18 Dec 2025 |
 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 |
