I'm currently trying to create a build.rs for a library crate. I would like to know if there is, and if there isn't request, an environmental variable that tells the build script where the user's Cargo.toml or root is located.
For example: I have crate Bar, which relies on Foo. I would like Foo's build script to be able to read Bar's Cargo.toml location or the directory path where Bar's Cargo.toml is located.
This would be incredibly useful if Foo wants to download a shared C library into Bar's directory.
Build scripts are not allowed to touch the source directory.
Cargo is moving towards using a global cache for build artifacts by default. This is incompatible with the env var you propose as the build.rs for a dependency would only run once even when used by different workspaces.
In Cargo, dependency trees can be very deep, and multiple different crates to use the same shared dependency, directly or indirectly.
This means that conceptually there's no clear "parent" crate for any dependency.
Currently there is a single workspace root, but that's not reliable either. There may be multiple equally important crates in the workspace. The workspace may not be using your Foo crate directly, but only indirectly via another dependency of a dependency.
And Cargo is planning to eventually have a global cache or pre-build crates.io crates, which means that there won't be even a context of a workspace for them.
Other limitations, which are typically imposed by Linux distros:
builds may be done in a read-only file system where you can't write anything anywhere except /tmp and OUT_DIR
builds may be done off-line, so you won't be able to download anything.
If you need a shared C library:
ask user to install the library using their package manager, or download and run an installer manually
as a fallback, add vendored library sources to your Rust sys crate, build it from source, and link statically