In reply to @qyliss:fairydust.space
IIRC the problem was that it didn't accomodate the possibility that you'd be building std and no_std targets at the same time.

In reply to @emilazy:matrix.org
Alyssa Ross: does this look like anything familiar? https://hydra.nixos.org/build/288008080/nixlog/1 looks like it broke when the useFetchCargoVendor cycle landed

finalAttrs.cargoDeps.patches is no longer valid (maybe null, idk can't check rn), since patches gets passed into cargoDeps.vendorStaging

there should probably be a way to pass attrs to the non-staging drv. Though, in this case we actually need to pass to the staging FOD.
So the fix is probably just using finalAttrs.cargoDeps.vendorStaging.patches

so the fix is literally just:

diff --git a/src/bootstrap/src/core/build_steps/doc.rs b/src/bootstrap/src/core/build_steps/doc.rs
index 8a9321f8e79..4bd212660dd 100644
--- a/src/bootstrap/src/core/build_steps/doc.rs
+++ b/src/bootstrap/src/core/build_steps/doc.rs
@@ -588,6 +588,9 @@ fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> {
 
     fn make_run(run: RunConfig<'_>) {
         let crates = compile::std_crates_for_run_make(&run);
+        if crates.is_empty() {
+            return;
+        }
         run.builder.ensure(Std {
             stage: run.builder.top_stage,
             target: run.target,

If I were to try and solve the issue of cross compiling for windows and pthreads (see https://github.com/NixOS/nixpkgs/issues/139966), what would be the best way to go about it? I would prefer to fix it so that it works with cargoBuildHook since I use that at work. Pretty much every Rust project I work on runs into this as all are crossed to Windows.

My best thought so far is to add a default CARGO_TARGET_X86_64_PC_WINDOWS_GNU_RUSTFLAGS = "-L native=${windows.pthreads}/lib" + args; or something in the build hook though I've not tried it yet.

o/ hoping for a bit of advice, I'm currently trying to set up a CI flow with crate2nix to test some code.

The tests involve spinning up a test environment with docker compose, though, so simply adding runTests won't work.

I'm using cargo nextest as a test runner, so AIUI in theory I should be able to build my tests (with cargo nextest run --no-run from a high level perspective) with nix, make the test binaries themselves the build output, and then outside of the nix context invoke cargo nextest run to actually run the tests.

Does this seem like a reasonable approach? Could it be something crate2nix is interested in as a supported use case? Any other ideas on how to handle tests like this?