| 17 Jan 2026 |
 Charles ⚡️ | while we're clarifying things, i believe this "can't" is not a "it just hasn't been done yet" situation but more a "it is not possible to do without losing the guarantee of repeatable builds which is kind of the point of nix" situation | 06:44:31 |
 debtquity | yea i am not well versed in either, but even if it's a marginal improvement. I think it would help resource wise. Just checking the build times on this project, it takes 37 minutes on hydra (build -> tests -> post install)
https://hydra.nixos.org/build/318543980 | 06:47:46 |
| debtquity | a bit surprised my machine builds faster than hydra ha | 06:48:13 |
| debtquity | wow, it takes an hour on aarch64-linux
https://hydra.nixos.org/build/318543984
| 06:49:29 |
| Charles ⚡️ | the thing is that improving incremental build times is irrelevant for nixpkgs because it already has so many things to build and when any of the dependencies of a thing change, it forces a clean build of the thing, so the only time you'd reap the benefits of fast incremental builds is when only leaf packages change, which i imagine is rare | 06:55:19 |
| Charles ⚡️ | e.g. if you have packages X and Y, and X depends on Y, and both X and Y are comprised of multiple derivations to enable incremental builds, and Y changes, having incremental builds for X is irrelevant because you need to rebuild it from scratch now | 06:57:30 |
| Charles ⚡️ | and breaking down packages into multiple derivations is pretty complex to implement | 06:58:24 |
| Charles ⚡️ | so for nixpkgs the tradeoff is between time saved on builds versus time spent making builds faster, and since rebuilds are so common, it just isn't worth it | 06:59:01 |
| Charles ⚡️ | * so for nixpkgs the tradeoff is between time saved on builds versus time spent making builds more incremental, and since rebuilds are so common, it just isn't worth it | 06:59:26 |
| Charles ⚡️ | but in other cases there are out-of-nixpkgs tools like crane that do address this problem, because the use-case for those is working on a package outside of nixpkgs where the dependencies change relatively rarely so that you can have fast builds most of the time, and in that case the tradeoff becomes worth it | 07:00:53 |
| Charles ⚡️ | you might argue that maybe it would be good to centralize efforts on such incremental build tools by implementing and using them in nixpkgs anyway so why not do that, and for that i have no answer lol. maybe some kind of social problem around disagreeing about how exactly to do implement such things, since they are more complicated than the existing one derivation per package (ish) status quo | 07:04:37 |
| Charles ⚡️ | * you might argue that maybe it would be good to centralize efforts on such incremental build tools by implementing and using them in nixpkgs anyway so why not do that, and for that i have no answer lol. maybe some kind of social problem around disagreeing about how exactly to implement such things, since they are more complicated than the existing one derivation per package (ish) status quo | 07:04:51 |
 Marien Zwart | There's also a build system element to it where in the autotools / meson world your dependencies are first built separately (so the natural way of building those with nix looks more like what crane does) while crane has to jump through some hoops to get cargo to approximate that approach | 07:05:42 |
| Charles ⚡️ | yeah, teaching all the build systems how to build each increment as its own derivation is one of the challenges and sources of complexity here | 07:06:51 |
| Charles ⚡️ | for example in the context of c/c++ you could attempt to take it even further and have one derivation for each object file plus one for the final link | 07:07:39 |
| Marien Zwart | Which would probably mean throwing upstream's build system away entirely (a lot of work for little benefit for a reasonably-sized package). (Could do that for rust too, derivation per rustc invocation instead of having cargo run that) | 07:11:10 |
| Marien Zwart | I don't think you can reasonably do this unless you can get the upstream build system to export its build graph, but unless that build system is something like bazel that also focuses on reproducible builds I doubt it's practical (...and the natural way of consuming that exported graph would be IFD so it still wouldn't work in nixpkgs) | 07:14:22 |
 eveeifyeve | In reply to @charles:computer.surgery
nix can't do incremental builds, it can only build complete derivations Wasn’t there a plan for this? | 13:23:07 |
 Theo Paris | It seems that mainline m1n1 doesn't build within nixpkgs, with the src overriden to this commit specifically https://github.com/HoolockLinux/m1n1/commit/19d973c873ad3f5396a23faaeb721b305b3d3cc1.
It complains about a missing vendored uuid dependency and a missing .cargo-checksum.json. I'm not sure how to properly fix this since it is not using buildRustPackage because it uses a makefile with mixed C/Rust sources | 21:01:07 |
| Theo Paris | * It seems that mainline m1n1 doesn't build within nixpkgs, with the src overriden to this commit specifically https://github.com/HoolockLinux/m1n1/commit/19d973c873ad3f5396a23faaeb721b305b3d3cc1.
It complains about a missing vendored uuid dependency and a missing .cargo-checksum.json. I'm not sure how to properly fix this since it is not using buildRustPackage because it uses a makefile with mixed C/Rust sources. Any ideas? | 21:01:21 |
| Theo Paris | I figured it out. Using cargoRoot = "rust" + cargoDeps + fetchCargoVendor seems to work. | 21:06:52 |
|  asa joined the room. | 22:10:04 |
| asa | i was looking through rust build infra in nixpkgs and found that lto is entirely opt in, which struct me as strange because lto=thin is the default for cargo and the rest of the rust ecosystem. is there a reason for this? | 22:15:04 |
| asa | i understand -O2 and no LTO by default for c/c++ packages since they could rely on UB that's broken by further optimization, but since the entire rust ecosystem defaults to -03 and thin lto (and rust programs usually don't violate the language's vm), it seems reasonable for that to be the default in nixpkgs as well | 22:18:17 |
 K900 | Rust ecosystem does not default to -O3 | 22:21:14 |
| K900 | Rust's optimization levels don't really map to C++ conventions | 22:21:23 |
| K900 | And even -C opt-level=3 is different from -O3 | 22:21:39 |
| K900 | And no, Cargo does not default to thinlto | 22:22:24 |
| K900 | https://doc.rust-lang.org/cargo/reference/profiles.html#release | 22:22:24 |
| K900 | [profile.release]
opt-level = 3
debug = false
split-debuginfo = '...' # Platform-specific.
strip = "none"
debug-assertions = false
overflow-checks = false
lto = false
panic = 'unwind'
incremental = false
codegen-units = 16
rpath = false
| 22:22:39 |
