| 16 Jan 2026 |
 accelbread | Has anyone gotten build-std working with nixpkgs rustc? | 05:57:29 |
 Logan Devine | thank ya, I'll try this out | 15:47:28 |
| 17 Jan 2026 |
|  roxie joined the room. | 03:33:14 |
| roxie set a profile picture. | 03:35:00 |
| roxie changed their profile picture. | 03:37:35 |
 debtquity | are there any tricks for speeding up local build times for rust packages in nixpkgs?
...
┏━ Dependency Graph:
┃ ✔ stalwart-0.15.3 ⏱ 21m29s
┣━━━ Builds
┗━ ∑ ⏵ 0 │ ✔ 1 │ ⏸ 0 │ Finished at 22:18:53 after 21m38s
20 minutes is wild
| 06:04:49 |
 Charles | try disabling runtime performance optimizations like codegen-units = 1 and lto = true https://github.com/stalwartlabs/stalwart/blob/22fc4a795d56264aefd082040c6998c9371b83aa/Cargo.toml#L46-L47 | 06:21:37 |
| Charles | not sure if that fits your "local" criteria though | 06:22:30 |
| debtquity | oh, i was hoping to do it from the building side without modifying the project | 06:22:44 |
| Charles | i don't know any such tricks unfortunately (but maybe someone else might?) | 06:23:11 |
| Charles | i mean, you could add patches to the derivation to make those changes via overrideAttrs, unless you really mean "without changing any nix code or upstream code" | 06:25:20 |
| debtquity | ah, i'll give that a shot. what do we lose with LTO, though? | 06:26:09 |
| Charles | https://doc.rust-lang.org/cargo/reference/profiles.html#lto | 06:26:46 |
| Charles | summary to the point of being unhelpful: you lose some performance | 06:27:20 |
 Marien Zwart | Should be about the same performance as a non-incremental release build, if it's way slower than that you may be building at cores = 1 or something along those lines | 06:28:07 |
| debtquity | makes sense, so then whatever I write in overrideAttrs shouldn't be pushed to nixpkgs :) | 06:28:13 |
| Charles | yeah | 06:28:31 |
| Charles | for in-nixpkgs stuff the runtime performance increase is possibly worth the build time increase since it can then be pulled by multiple users from the binary cache without having to build it themselves | 06:30:40 |
| debtquity | another thing i notice is that everytime i run nix build ./#package, it re-compiles all of the project. I thought rust had some build cache mechanism? | 06:33:36 |
| Charles | rust does, nix doesn't | 06:33:51 |
| debtquity | or maybe that's just the nature of nix? | 06:33:57 |
| debtquity | ooh | 06:33:59 |
| Charles | * rust (cargo, more accurately) does, nix doesn't | 06:34:00 |
| debtquity | so nixpkgs function would need to be improved then | 06:34:29 |
| Charles | nix can't do incremental builds, it can only build complete derivations | 06:34:38 |
| Charles | you can sort of get incremental builds with nix by breaking up the build into multiple derivations, but that gets complicated | 06:35:03 |
| Charles | https://crane.dev kind of does this by splitting the nix builds into two derivations, one for all dependencies, and one for the final binary crate, which helps in some cases but not all, and can't be used in nixpkgs | 06:35:50 |
| Charles | nixpkgs doesn't really care about incremental build times since it has to rebuild everything from scratch often enough anyway | 06:36:11 |
| Marien Zwart | Depending on what you're doing, crane's separate derivation for dependencies can help a lot (but of course means using crane, not pure nixpkgs) | 06:36:31 |
| Marien Zwart | and that's not the same level of incremental builds cargo can provide outside nix | 06:37:18 |
