| 19 Jul 2025 |
 Toma | Is there any way (that is acceptable inside nixpkgs) to build a rust based project using only LLVM/clang?
I'm seeing that the rustc's setEnv is using gcc even if I try to provide a different stdenv for buildRustPackage. | 22:58:02 |
| Toma | * Is there any way (that is acceptable inside nixpkgs) to build a rust based project using only LLVM/clang? (on linux)
I'm seeing that the rustc's setEnv is using gcc even if I try to provide a different stdenv for buildRustPackage. | 22:58:16 |
 Tristan Ross | pkgsLLVM is a good way | 23:03:16 |
 emily | I think we bake that stuff in annoyingly early | 23:03:17 |
| emily | we tried to get rid of setEnv but had to put it back | 23:03:29 |
| emily | In reply to @rosscomputerguy:matrix.org
pkgsLLVM is a good way not for an individual package in Nixpkgs though? | 23:03:44 |
| Tristan Ross | In reply to @emilazy:matrix.org
not for an individual package in Nixpkgs though? True | 23:03:57 |
| emily | I think you might be able to produce a buildRustPackage that bakes in a different compiler but trying to kill setEnv again may be more fruitful | 23:04:26 |
| 20 Jul 2025 |
 Randy Eckenrode | Unfortunately, no (not currently). setEnv uses pkgsBuildHost.stdenv.cc, which rustPlatform doesn’t provide a way to override. | 14:52:53 |
| Randy Eckenrode | This was a motivating use case for taking libSystem out of the stdenv in the SDK rework. Overriding the SDK prior to that varied from difficult to impossible. | 14:54:28 |
| 21 Jul 2025 |
 rosssmyth | Note: Some breaking changes to the JSON target format will probably be merged to rustc soonish. I know Nixpkgs exposes that as an API so for anyone relying on it, they should be aware. | 02:21:56 |
| rosssmyth | https://github.com/rust-lang/rust/pull/144218 | 02:22:16 |
|  wonrax joined the room. | 09:29:07 |
| 22 Jul 2025 |
| wonrax set a profile picture. | 06:11:48 |
|  @federicodschonborn:matrix.org changed their display name from The Worm 🏳️🌈 (he/they) to Wormy McWormface 🏳️🌈 (he/they). | 18:27:45 |
| 23 Jul 2025 |
|  theeasternfurry joined the room. | 02:11:18 |
 Gaétan Lepage | In reply to @glepage:matrix.org
Looks like rustfmt is broken on x86_64-darwin on nixos-25.05:
https://buildbot.nix-community.org/#/builders/2847/builds/5266/steps/1/logs/stdio (from Nixvim CI) Opened a PR with a fix: https://github.com/NixOS/nixpkgs/pull/427702 | 15:46:30 |
| Toma | I think we can agree that fetchCargoVendor being a two step construction is not very good for the cache.
Now, we could move the calling of the "fetch-cargo-vendor-util create-vendor" into cargoSetupHook, but that would create a dependency on fetch-cargo-vendor-util for every rust package.
Now I think I came up with a pretty clever workaround, which keeps the two layers, but makes the non-FOD layer essentially just an empty derivation except a binary that you can run to start the unpacking process.
This way we just have to detect if that unpacking binary is present in cargoDeps inside cargoSetupHook and then call it.
Though, this would make it so that we can't "easily" get derivation with the vendored dependencies unpacked from the tarball.
But, we could provide a passthru.vendorFetched (things in passthru don't get build by CI) which just runs the unpacking logic into "$out"
(Also, I put in a symlink into the non-FOD part for vendorStaging for easier access)
I made a very rudimentary POC: https://github.com/NixOS/nixpkgs/pull/427815
Note: I did not take into consideration cross/splicing
What do you all think?
| 17:45:49 |
| emily | "a dependency on fetch-cargo-vendor-util for every rust package" doesn't seem like an issue, does it? | 17:47:21 |
| emily |
90% of Rust packages will already have that dependency and it's just a lightweight Python script, yeah?
| 17:47:31 |
| emily | * >90% of Rust packages will already have that dependency and it's just a lightweight Python script, yeah? | 17:47:36 |
| Toma | I worry about inf-rec since the fetch-cargo-vendor-util depends on cargo, which depends on cargoSetupHook IIRC.
I havr not tried it though | 17:50:46 |
| Toma | * I worry about inf-rec since the fetch-cargo-vendor-util depends on cargo, which depends on cargoSetupHook IIRC.
I have not tried it though | 17:51:03 |
| emily | usually we use overrides to solve that | 17:54:18 |
| emily | (cargoSetupHook.override { fetch-cargo-vendor-util = null; }) | 17:54:29 |
| Toma | True | 17:54:45 |
| Toma | I'm assuming that some people are using a custom implementation for vendoring. (e.g. for some authentication logic IDK) and their logic assumes that cargoSetupHook expects an unpacked cargo vendor structure.
So I don't think we should unconditionally use fetch-cargo-vendor-util if we detect that cargoDeps is a directory.
We'd have to conditionally run our logic, only when we know we're using something that was generated by fetchCargoVendor
However, we can't really put any distinction marker files into vendor-staging, since that's a FOD.
But maybe I'm overthinking this.
Yes getting rid of the two steps would be healthier for easier overriding of hashes via overrideAttrs
Anyways, I have to go now... I'll be back in an hour or so, sorry!
| 17:59:23 |
| emily | we could expect such users to override it out of the setup hook | 18:00:53 |
| emily | we probably should have added a marker though 😅 | 18:01:04 |
| emily | wait | 18:01:08 |
