 | Nix Cross Compiling | 566 Members |
| 123 Servers |
| Nix Cross Compiling | 566 Members |
| 123 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 Dec 2025 | ||
 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.
| 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 |
| 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.orgLuckily it's easy to use a old nixpkgs revision | 13:46:34 |