CargoMetadata doesn't work when udeps is building code

[jvimal-eg]

I am trying to run udeps on a workspace with many crates, and I see this error below:

The build.rs file line 2 where the stack trace points to doesn't have anything. I think it's probably a function call injected into the build script by cargo that's looking for project metadata?

I can't --exclude this crate because it's a common dependency across other crates in the workspace.

Any thoughts on what could be the issue?

error: failed to run custom build command for `proto-helpers v0.1.0 (proto-helpers)`

Caused by:
  process didn't exit successfully: `/Users/jvimal/.cargo/target/debug/build/proto-helpers-785ed3443d96513f/build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-changed=Cargo.toml
  cargo:rerun-if-changed=../Cargo.lock
  cargo:rerun-if-changed=build.rs
  cargo:rerun-if-changed=src/lib.rs

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: CargoMetadata { stderr: "error: Found argument 'metadata' which wasn't expected, or isn't valid in this context\n\nUSAGE:\n    cargo <SUBCOMMAND>\n\nFor more information try --help\n" }', /Users/jvimal/.cargo/registry/src/github.com-1ecc6299db9ec823/build-info-build-0.0.23/src/build_script_options/crate_info.rs:37:10
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/40d23020470db06903589e210c83a4936f22d52a/library/std/src/panicking.rs:515:5
     1: core::panicking::panic_fmt
               at /rustc/40d23020470db06903589e210c83a4936f22d52a/library/core/src/panicking.rs:92:14
     2: core::result::unwrap_failed
               at /rustc/40d23020470db06903589e210c83a4936f22d52a/library/core/src/result.rs:1355:5
     3: core::result::Result<T,E>::unwrap
               at /rustc/40d23020470db06903589e210c83a4936f22d52a/library/core/src/result.rs:1037:23
     4: build_info_build::build_script_options::crate_info::read_manifest
               at /Users/jvimal/.cargo/registry/src/github.com-1ecc6299db9ec823/build-info-build-0.0.23/src/build_script_options/crate_info.rs:31:13
     5: build_info_build::build_script_options::BuildScriptOptions::drop_to_build_info
               at /Users/jvimal/.cargo/registry/src/github.com-1ecc6299db9ec823/build-info-build-0.0.23/src/build_script_options/mod.rs:49:20
     6: <build_info_build::build_script_options::BuildScriptOptions as core::ops::drop::Drop>::drop
               at /Users/jvimal/.cargo/registry/src/github.com-1ecc6299db9ec823/build-info-build-0.0.23/src/build_script_options/mod.rs:106:22
     7: core::ptr::drop_in_place<build_info_build::build_script_options::BuildScriptOptions>
               at /rustc/40d23020470db06903589e210c83a4936f22d52a/library/core/src/ptr/mod.rs:192:1
     8: build_script_build::main
               at ./build.rs:2:37
     9: core::ops::function::FnOnce::call_once
               at /rustc/40d23020470db06903589e210c83a4936f22d52a/library/core/src/ops/function.rs:227:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
error: build failed

[est31]

I think it's because the cargo-udeps binary acts as cargo binary, and when the build.rs script tries to run cargo metadata, it invokes cargo-udeps with the metadata subcommand, which it doesn't recognize I think? Not sure.

[jvimal-eg]

@est31 Here's a minimal reproducible example. It might be an issue with the build_info crate I am using, but not sure at the moment. The stack trace is originating at the build_info_build::build_script(); function call in build.rs.

/bin/ls
Cargo.lock	Cargo.toml	lib

cat Cargo.toml
[workspace]
members = ["lib"]

cat lib/Cargo.toml
[package]
name = "lib"
version = "0.1.0"
authors = ["xx"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
build-info = "0.0.23"

[build-dependencies]
build-info-build = "0.0.23"

cat lib/build.rs
fn main() {
    build_info_build::build_script();
}

cat lib/src/lib.rs
build_info::build_info!(pub fn version);

[jvimal-eg]

@est31 were you able to find out why this is happening? I tried to look into the code, but couldn't figure this out.

[est31]

@jvimal-eg have you got my reply? Cargo udeps needs to be able to be called with the metadata subcommand. I'm just not sure how to implement this nicely.

[ValHeimer]

I confirm I have the same issue when having cbindgen::generate(&crate_dir).unwrap(); in my build.rs

[Logarithmus]

@jvimal-eg have you got my reply? Cargo udeps needs to be able to be called with the metadata subcommand. I'm just not sure how to implement this nicely.

@est31 so basically cargo udeps is unusable for crates with build.rs, right? I guess it would be easy to just run cargo metadata if cargo udeps metadata is being run, what's unnice about that solution? Sorry, don't know much about the internals of cargo udeps.

[est31]

cargo udeps is unusable for crates with build.rs, right?

It depends on what the build.rs tries to do. If it calls cargo metadata, it might cause issues, yes.