Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add env vars specifying the path for the dependent crate when compiling a dependency #13636

Closed
transbitch opened this issue Mar 24, 2024 · 2 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@transbitch
Copy link

transbitch commented Mar 24, 2024

Problem

When building a dependency, currently it is not possible for the dependency to find the path for the dependent crate (e.g. if foo depends on bar, bar can't find foo's manifest).

Proposed Solution

I suggest adding two new env vars to both build scripts and crates*:

  • CARGO_DEPNT_MANIFEST_DIR points to the crate which directly depends on this crate (the "dependent")
  • CARGO_TARGET_MANIFEST_DIR points to the crate which is being built.

Currently, CARGO_TARGET_MANIFEST_DIR can be found from a build script by looking at OUT_DIR and then traversing up the directory tree until a Cargo.toml is found. I'm not sure if CARGO_DEPNT_MANIFEST_DIR can be found.

*It doesn't really make sense to limit it to buildscripts. Someone may want to include!, and people can just set up a build script to pass it through anyways.

Use case

A library may want to read a config file in the user's crate, or data from the metadata field of Cargo.toml. Currently, that isn't possible. Instead, the library must use features (which are binary on/off) or env variables (which are just strings). Cargo.toml provides structured data beyond bools and strings. See #8375

@transbitch transbitch added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Mar 24, 2024
@epage
Copy link
Contributor

epage commented Mar 25, 2024

Sounds like you want the top-most dependent, right? There isn't guaranteed to be one dependent due to workspaces.There is a request for the workspace in #3946 and config is brought up in it, see https://github.com/jamesmunns/toml-cfg

See also #13484

That said, this inverts cargo's dependency relationship and i wonder if it'd be better served with https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618

@epage
Copy link
Contributor

epage commented Mar 25, 2024

Closing in favor of #13484. If there is a reason we should keep this open separately, let us know!

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Mar 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants