Providing path to originally selected manifest file

[wmmc88]

Problem

When running cargo commands like cargo build, packages are automatically selected based off of the cargo manifest selected (either based off of the current working directory of the invocation or the --manifest-path argument). AFAIU, a dependency graph is generated based off of this manifest and then the build is executed. By this logic, before any build-script runs, cargo already knows all of the packages that need to be built and has access to all of its manifest data. I want to access that data in one of the dependency's build.rs.

I have 2 crates- crate A and crate B. crate B has a path dependency on crate A. I would like to be able to read custom metadata in crate B's manifest by using cargo_metadata from within crate A's build.rs. This metadata is something like a globally configured feature proposed in https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618/38. When running cargo metadata cli command from crate B's directory, I can see the metadata in the crate B's manifest, but when getting metadata via crate A's build.rs, I cannot. If both crates existed in the same workspace, it would work, but I intend for crate A to be able to be consumed by others to use and configure via metadata in user's dependent crates.

If the originally selected manifest path was provided to build scripts, I could point to that manifest when using cargo_metadata in crate A's build.rs. As it stands, I need to use OUT_DIR to derive where the selected/root manifest of the build is, but this is fragile and does not work when the default target directory is changed by things like --target-dir(similar issue to #9661 ).

Proposed Solution

A environment variable provided to builds scripts that exposes to originally selected manifest path.

Notes

seems like a similar feature request to #8148

[weihanglo]

... cargo already knows all of the packages that need to be built and has access to all of its manifest data. I want to access that data in one of the dependency's build.rs.

This kind of inverse relation that a dependency knows the full picture of a build sounds a bit odd. Could you elaborate more on what you actually want to achieve?

BTW, there is a relevant issue #3946 about finding the root workspace, and the current experiment of that is an unstable env var CARGO_RUSTC_CURRENT_DIR you might be interested in.

[wmmc88]

This kind of inverse relation that a dependency knows the full picture of a build sounds a bit odd. Could you elaborate more on what you actually want to achieve?

I have a sys crate who's bindings are globally configurable. I want to be able to configure the bindings based off of info in the metadata table in downstream crates. I also considered configuring it via cargo features, but features are meant to be additive and not mutually exclusive, and I also think this metadata approach is a better user experience. More context here: microsoft/windows-drivers-rs#82 (comment)

I need a path to pass to MetadataCommand.manifest_path such that the output matches running cargo metadata from the directory that cargo build was invoked in. My understanding is that providing the path to directory with the Cargo.lock file should achieve what I want.

From the description of CARGO_RUSTC_CURRENT_DIR, it looks like it would also work for my usecase, but unfortunately it looks like it is not exposed to build scripts.