!FBuJyWXTGcGtHTPphC:nixos.org

Nix Rust

593 Members
Rust132 Servers

Load older messages


SenderMessageTime
30 Jun 2025
@apyh:matrix.orgapyh yo dpc (migrated to @dpc:dpc.pw) , if you're still active on this account -
i'm trying to do some crane + maturin stuff and came across a 2 yr old reddit thread where you mentioned you've done some work with it.
do you have any public code showing how it works?
trying to shove a maturin build --offline into a craneLib.buildPackage is causing me to recompile things, and i can't get a nice deterministic name for the output wheel thru maturin.
16:53:37
@fxomt:pub.solarfxomt (lemmy.dbzer0.com) [he/him] changed their display name from fxomt to fxomt (lemmy.dbzer0.com) [he/him].18:18:16
@setthemfree:matrix.orgundltd When I update nixpkgs input in my flake.nix for a Rust package from 24.11 to 25.05, I get a hash mismatch on cargoHash, although I didn't change anything in Cargo.lock. Is that typical? I.e., cargoHash depends not only on Cargo.lock, but also on nixpkgs? 19:36:02
@k900:0upti.meK900In this case yes19:36:44
@k900:0upti.meK900The FOD format has changed19:36:48
@qyliss:fairydust.spaceAlyssa RossBut it shouldn't ever happen again 🤞19:37:28
@setthemfree:matrix.orgundltdI see, thanks!19:38:15
1 Jul 2025
@niklaskorz:matrix.orgniklaskorzzed-editor had a huge build time increase on darwin in the past month (roughly takes twice as long now, 1h on my local Macbook vs 30min before that, 2 hours on hydra vs 1 hour before that), and I wonder if disabling thin LTO (enabled by upstream) + increasing cargo codegen units (set to 1 by upstream) could be a viable improvement? it’s getting kind of tedious to review updates at this point, so any suggestions would be appreciated...07:58:14
@niklaskorz:matrix.orgniklaskorzLinux build time also slightly increased, but only by about ten minutes on hydra, so that is still in an acceptable margin07:58:48
@niklaskorz:matrix.orgniklaskorzthese are the profiles currently set by upstream’s Cargo.toml:08:01:13
@niklaskorz:matrix.orgniklaskorz
[profile.release]
debug = "limited"
lto = "thin"
codegen-units = 1

[profile.release.package]
zed = { codegen-units = 16 }

[profile.release-fast]
inherits = "release"
debug = "full"
lto = false
codegen-units = 16

(not sure where they use release-fast)
08:01:20
@qyliss:fairydust.spaceAlyssa RossI think in general slow build times for improve runtime performance is what we want in Nixpkgs where people are mostly using Hydra binaries, but it would make sense for that to be standardised rather than following Cargo.toml for each package.08:02:33
@niklaskorz:matrix.orgniklaskorzhm I see, I just wonder where the build time increase could be coming from, the release profiles seem to be unchanged in the past months, so that’s at least not the origin08:03:54
@qyliss:fairydust.spaceAlyssa RossYou could consider overriding it for review and taking the risk on there not being divergence08:03:57
@qyliss:fairydust.spaceAlyssa Ross
In reply to @niklaskorz:matrix.org
hm I see, I just wonder where the build time increase could be coming from, the release profiles seem to be unchanged in the past months, so that’s at least not the origin
Rust update perhaps? If it's something unintended it could perhaps be discovered, reported and fixed. Is it bisectable?
08:04:59
@niklaskorz:matrix.orgniklaskorzI hoped to avoid bisecting because of the large build times, but maybe I can speed it up a bit by disabling the check phase 😄 (both buildPhase and checkPhase had an equal increase in build time, so that should suffice)08:06:57
@niklaskorz:matrix.orgniklaskorzwill do and report back08:07:01
@qyliss:fairydust.spaceAlyssa RossWell, if you have a Rust update in range, you could speculate that it's that and test that first rather than doing a whole Nixpkgs bisect08:09:23
@qyliss:fairydust.spaceAlyssa RossWhen I bisect I'm also scanning the commits in range to find likely causes, not always following the midpoint it gives me to test.08:09:59
@niklaskorz:matrix.orgniklaskorzright, thanks! I’ll start with the Rust 1.86 -> 1.87 commit then08:11:22
@dramforever:matrix.orgdramforever

Idea smoke test: Problem: You probably don't understand what on earth the difference between cargoShortTarget, rustcTarget, and rustcTargetSpec is

nix-repl> stdenv.hostPlatform.rust
{
  cargoEnvVarTarget = "AARCH64_UNKNOWN_LINUX_GNU";
  cargoShortTarget = "aarch64-unknown-linux-gnu";
  isNoStdTarget = false;
  platform = { ... };
  rustcTarget = "aarch64-unknown-linux-gnu";
  rustcTargetSpec = "aarch64-unknown-linux-gnu";
}

These are only different if you specify rust.platform, in which case it behaves very counterintuitively:

nix-repl> (lib.systems.elaborate { config = "x86_64-unknown-linux-gnu"; rust.platform = { fake = "json"; }; }).rust
{
  cargoEnvVarTarget = "1P406CKXYZARK9J8L3LSZSJCD1VSDGNL_X86_64_UNKNOWN_LINUX_GNU";
  cargoShortTarget = "1p406ckxyzark9j8l3lszsjcd1vsdgnl-x86_64-unknown-linux-gnu";
  isNoStdTarget = false;
  platform = { ... };
  rustcTarget = "x86_64-unknown-linux-gnu";
  rustcTargetSpec = "/nix/store/1p406ckxyzark9j8l3lszsjcd1vsdgnl-x86_64-unknown-linux-gnu.json";
}

As it stands today ~nobody gets it right. Nixpkgs docs lies about the file name of rustcTargetSpec if it's a JSON. cargoShortTarget, rustcTarget, and rustcTargetSpec are used interchangably everywhere in Nixpkgs.

Idea: cargoShortTarget == rustcTarget. Snag: If there's a JSON spec, cargoShortTarget must be the base name sans extension of the JSON file, and AFAICT can't make a directory with only `lib

Proposal:

Phase 1:

  • Create rustPlatform.targetSpec and rustcPlatform.targetSpecFor (latter being function taking a platform)
  • rustcTarget = cargoShortTarget
  • If rust.platform is set, make rustcTargetSpec error out, else rustcTargetSpec = cargoShortTarget
  • Change docs to ask user to set rust.{cargoShortTarget,platform} (instead of rust.{rustcTarget,platform})
  • Fix every user in Nixpkgs

Phase 2:

  • Deprecate and remove rustcTarget and rustcTargetSpec

See: https://github.com/NixOS/nixpkgs/pull/420797#pullrequestreview-2969405491

14:04:02
@qyliss:fairydust.spaceAlyssa RossWe deliberately moved these out of rustPlatform and into lib.systems14:20:59
@qyliss:fairydust.spaceAlyssa RossAnd I broadly disagree that almost nobody gets it right14:23:27
@dramforever:matrix.orgdramforever how about something that takes a pkgs, like emulator? 14:31:21
@qyliss:fairydust.spaceAlyssa Ross That's a very bad pattern that completely defeats the purpose of lib. Absolutely not a precedent to build on 14:32:08
@dramforever:matrix.orgdramforever then we would need to make either users adapt if they want to support rust.platform, or some way to generate a directory without pkgs 14:34:00
@qyliss:fairydust.spaceAlyssa RossLayering violation14:36:37
@qyliss:fairydust.spaceAlyssa RossThe rust-hypervisor-firmware package is also doing something deeply wrong (reimporting Nixpkgs) and as a result hasn't worked for the majority of time it's been in Nixpkgs. It's not a good example of what we'd like to accommodate. The only reason it was done that way was that at the time our normal Rust compiler couldn't build for embedded targets due to an upstream bug that has since been fixed.14:36:38
@dramforever:matrix.orgdramforever okay let's put aside rust-hypervisor-firmware for now, and focus on why i want to merge rustcTarget and cargoShortTarget 14:41:29
@dramforever:matrix.orgdramforeveryou say that you disagree that almost nobody gets it right?14:41:48

Show newer messages


Back to Room ListRoom Version: 6