| 18 Dec 2025 |
 matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | or at least that's the goal, and there's enough evidence of things being introduced that don't work like that in the past being stuck in nixpkgs that people rely on | 13:21:56 |
 bake.monorail | I'm looking at LLVM, there aren't a lot of patches, but yeah. | 13:22:21 |
 K900 | You can go look at any previous GCC version removal PR | 13:22:25 |
| K900 | Or LLVM for that matter | 13:22:30 |
| K900 | To see how much code those end up dropping | 13:22:36 |
| bake.monorail | what project are you talking about? nix?
is nix supposed to build with all the compilers in nixpkgs? I'm not saying that anything should build with it, just make the compiler available. | 13:23:08 |
| K900 | I'm talking about the cc-wrapper | 13:23:19 |
| K900 | Which is a component in nixpkgs that wraps compiler executables to make them behave the way we want | 13:23:35 |
| bake.monorail | to be honest I'd be happy to have older clangs even without the cc-wrapper, but I understand mine could be a niche use case. | 13:25:10 |
| bake.monorail | I'll take a look | 13:25:42 |
| bake.monorail | keeping old compilers building is not so hard, in my experience is just some new compiler error, nothing incredibly hard to patch. it's also useful for bootstrapping systems. I think it'd be valuable.
but yeah, it takes some effort. I'm curious about what features cc-wrapper needs. in my understanding it's just adding a bunch of compiler flags, but I didn't look too hard into it. | 13:29:04 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | I mean, the reason anything would get dropped is because it's not working, so if you don't want to drop it you could just make PRs | 13:29:35 |
| bake.monorail | are you sure? AFAIU there's a policy about dropping end-of-life'd compilers. I don't think they necessarily "do not work" | 13:30:21 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | otherwise if it's like gccX where X is old, then no | 13:30:41 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | you can't keep everything always forever, that's what you use old releases of nixpkgs for | 13:31:02 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | I mean, provide it as an overlay or flake then if you feel that way? | 13:32:48 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | https://github.com/autc04/Retro68 | 13:32:49 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | check that out | 13:32:52 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | the maintenance status of retro68 makes it pretty valid for inclusion in nixpkgs instead of being its own flake though | 13:33:11 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | whereas an out-of-date unmaintained thing is less relevant for nixpkgs inclusion | 13:33:30 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | still shows how you can provide all that infra just fine outside of nixpkgs though | 13:33:46 |
| matthewcroughan @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | 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 @ 39c3 (DECT 94667 or 97340 or 67192) | And that there's nothing too bad about providing toolchains in overlays | 13:36:41 |
