Passing environment variables from down-stream to up-stream library

[ccll]

(Moved and re-phrased from #97)

Currently cargo can pass env vars from up-stream dependencies to down-stream, with user-defined metadata.

But what's still lacking is the reversed control, where up-stream library expects a env var to be set to build successfully, and down-stream must fill the env var for it.

This scenario is common in FFI libraries wrapping existing C lib, for example meh/rust-ffmpeg-sys expects the env var FFMPEG_DIR to be set to the path of pre-built C FFMpeg libs & binaries.

[norru]

I need this too!

My use case is to dynamically search for the most appropriate value of BOX2D_INCLUDE_PATH when using wrapped2d (https://github.com/Bastacyclop/rust_box2d). At the moment the options are:

• tell the user to set the variable manually, which is bad for automation and introduces much friction
• wrap the Cargo invocation in a batch file, which is not very IDE friendly (requires per-user setup, not platform agnostic, generally clunky)
• forcing the user to install the library at a very specific location, such as C:\ProgramData\Box2D

In all cases I need to provide Cargo with an absolute path, which is also very impractical. I have tried providing the full pre-built lib binaries in my project tree, together with all the .h files. Library links fine as it can be configured via build.rs but I could not find a reliable mechanism to reference the headers via a relative or dynamically discovered path.

The sequence would be:

• run a pre_build.rs (name TBD) script, configurable via Cargo.toml, which merges the current env with a set of custom, arbitrary env vars. This should replace the current kludge with batch files/shell scripts
• after pre_build.rs successfully completes, build all dependencies, in the scope of the environment above
• run the build.rs script as normal, in the scope of the environment above

This is so annoying that I am starting to look for Rust native physics libraries to replace Box2D altogether. Which is a shame as I'm otherwise super happy with both Box2D and the wrapped2d.

Cheers!

[axos88]

I need this too to be able to cross-compile with openssl dependency without having to invoke cargo like this every time: SYSROOT=/Volumes/ct-ng/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot OPENSSL_LIB_DIR=$SYSROOT/lib OPENSSL_INCLUDE_DIR=$SYSROOT/usr/include cargo build --target arm-unknown-linux-gnueabihf

[mberndt123]

+1 for the cross compilation scenario. When you depend on a crate that uses pkg-config to discover some C library, it would be nice to be able to set PKG_CONFIG_SYSROOT_DIR_mips-unknown-linux-musl in ~/.cargo/config once and be done with it

[joejune]

Me too, I want to set ARMV7_LINUX_ANDROIDEABI_OPENSSL_DIR to use a prebuilt openssl.

[ncalexan]

I also want Cargo to pass environment variables configuring the location of OpenSSL headers and libraries. In my case I'm cross compiling and the variables depend on the current target/toolchain.

[m-hilgendorf]

Any progress on this, or guidance on how to get started with a PR?

I have a use case where a crate needs to know the install location of a closed source SDK, which typically isn't placed in a user's $PATH since it can be useful to have multiple SDK versions installed at the same time.

Alternatively, adding an [env] section to the ./cargo/config file would work great.

[thedavidmeister]

same thing with libzmq here