| 11 Jul 2025 |
 cpick | It looks like I just needed to use br s -r rust_panic (not b) in lldb and that works just fine.
Thank you both!
| 18:11:30 |
 Toma | Oh, I was wrong about cargoDepsName not being used, I just misremembered. The important thing is: it no longer affects the hash. The old fetchCargoTarball implementation generated a tarball that had a directory name inside it dependent on the name of the package.
Now, with fetchCargoVendor, we no longer care about the names, the only thing that matters now is the exact contents of the Cargo.lock file: if anything changes in it, the hash will have to be regenerated.
This is because the Cargo.lock is copied into the FOD for later validation.
So, because the Cargo.lock file usually contains the version of the package, even if no deps were changed, the changed version value would lead to a new hash.
If we removed the Cargo.lock integrity check (where it checks if cargoDeps's Cargo.lock and src's Cargo.lock match), we'd no longer have to copy Cargo.lock into our FOD, so we'd only get a new hash if the dependency list changed.
This is not worth it compared to the integrity check, which is pretty important.
| 20:02:39 |
| 12 Jul 2025 |
 undltd | Thanks for the explanation. | 06:50:06 |
| undltd | I wonder what's the use case for setting cargoDepsName explicitly then? Like, why would anyone need to set that when defining a package? | 12:56:37 |
| Toma | I think we just forgot to remove it. idk | 12:57:07 |
| undltd | gotcha | 12:57:31 |
| 13 Jul 2025 |
 rosssmyth | You can always try this thingy I made a few weeks ago
https://github.com/RossSmyth/nur/tree/main/msvc-rust
I need to put some more work into it probably. | 02:40:57 |
| rosssmyth | Some of the situation with Windows would be eased if nixpkgs switched to the ucrt as it is not quite as cursed | 02:41:41 |
 Andrew | In reply to @rosssmyth:matrix.org
You can always try this thingy I made a few weeks ago
https://github.com/RossSmyth/nur/tree/main/msvc-rust
I need to put some more work into it probably. This is just rustc. I don't see it uses and of the msvc libraries or linker. | 07:07:35 |
| Andrew | Right now, I'm still using the container as I don't have time for more side quests. I'm already on one. | 07:08:37 |
 K900 | I had a similar thing set up with https://gitlab.com/K900/rust-cross-windows | 07:08:43 |
| K900 | But again this only handles pure Rust | 07:09:14 |
| K900 | You need to bring your own native deps built for MSVC | 07:09:23 |
| K900 | And that's where the fun starts | 07:09:27 |
| K900 | Or ends, depending on your definition of fun | 07:09:39 |
| K900 | @rosssmyth you may be interested for your own stuff though | 07:10:13 |
| K900 | It's significantly less janky | 07:10:17 |
| K900 | At least at a glance | 07:10:23 |
| Andrew | I just added slightly patched dx, and dependences: pkg-config, python3, nsis, libssl-dev. The image is 5.8 GiB though... I mount my cargo registry and project dir, which helps. The quick rebundle takes about 40 seconds. | 07:12:05 |
| Andrew | In reply to @k900:0upti.me
But again this only handles pure Rust Well, it has xwin, winsdk and the toolchain. The only thing missing from container is wine, I guess. | 07:16:30 |
| K900 | The problem is that you have native deps | 07:17:12 |
| K900 | Presumably | 07:17:13 |
| K900 | As in, deps that need to be built for Windows that are not Rust | 07:17:25 |
| Andrew | For now, I only have dependencies on weview2 | 07:17:45 |
| Andrew | Maybe openssl too, but I don't know if/how msvc uses it | 07:18:15 |
| Andrew | I do remember that several programs including mine depend on redistributable C++ runtime stuff. | 07:19:15 |
| Andrew | But that's it. | 07:19:21 |
| Andrew | In reply to @k900:0upti.me
As in, deps that need to be built for Windows that are not Rust Oh, I though pure rustc. Okay. But why no wine? Is it not needed? | 07:20:59 |
| Andrew | Theoretically this should work for my app. | 07:21:24 |
| K900 | Why do you need wine? | 07:21:36 |
