| 18 Dec 2025 |
 matthewcroughan | like if it's an esoteric compiler/stdenv you're talking about I'm sure that's fine, as long as someone's maintaining it | 13:30:23 |
| matthewcroughan | otherwise if it's like gccX where X is old, then no | 13:30:41 |
| matthewcroughan | you can't keep everything always forever, that's what you use old releases of nixpkgs for | 13:31:02 |
| matthewcroughan | and then you can maintain that in your own repo, with your own overlays, if you're truly serious about it | 13:31:16 |
| matthewcroughan | If it's "not that hard" as you say, then why not just keep an overlay? Not that hard either? | 13:31:55 |
 bake.monorail | I think compilers could be an exception due to their role in enabling building other software. but yeah, I feel like we're delving more on opinions rather than hard facts about what's specifically hard. | 13:32:16 |
| matthewcroughan | I mean, provide it as an overlay or flake then if you feel that way? | 13:32:48 |
| matthewcroughan | https://github.com/autc04/Retro68 | 13:32:49 |
| matthewcroughan | check that out | 13:32:52 |
| matthewcroughan | the maintenance status of retro68 makes it pretty valid for inclusion in nixpkgs instead of being its own flake though | 13:33:11 |
| matthewcroughan | whereas an out-of-date unmaintained thing is less relevant for nixpkgs inclusion | 13:33:30 |
| matthewcroughan | still shows how you can provide all that infra just fine outside of nixpkgs though | 13:33:46 |
| matthewcroughan | Like, overlays, overrideAttrs, override, all provide you with ways of achieving what you want to do, you can't keep everything forever in the tree | 13:35:37 |
| bake.monorail | I feel you're being a bit unnecessarily adversarial. this said, having an overlay is quite different story, since it does not enable you to reuse "private" logic from nixpkgs.
for instance, in the GCC package it's not possible to override the versions without forking (there's a "private" variable determining the versions). | 13:35:42 |
| bake.monorail | * I feel you're being a bit unnecessarily adversarial. this said, having an overlay is a quite different story, since it does not enable you to reuse "private" logic from nixpkgs.
for instance, in the GCC package it's not possible to override the versions without forking (there's a "private" variable determining the versions). | 13:36:13 |
| matthewcroughan | Not at all trying to be adversarial, just stating that if you want something like you're asking for, you should maintain it in your own tree, and this is what other people do too | 13:36:18 |
| matthewcroughan | And that there's nothing too bad about providing toolchains in overlays | 13:36:41 |
| matthewcroughan | 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 | 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 |
