Pass environment variables to dependencies.

[TyOverby]

For cargo's build scripts, it would be handy to be able to pass arguments to them via environment variables.

Usage would look something like:

[dependency.foo]
git = "......"
env = ["BAR", "BAZ", "A=B"]

[alexcrichton]

What sort of variables were you thinking of passing? I'd rather give more variables by default than add custom ones, but I could see both happening.

[TyOverby]

In my case it would be for building C libraries. The user could pass environment variable to my shell script that cargo runs when it runs the build command for my package. My shell script would decide what do do, and continue with compilation.

(The build command that I'm referring to is called "The build Field" on http://crates.io/manifest.html).

[TyOverby]

As an example, gl-rs uses environment variables during the library build phase.

[alexcrichton]

Do you have an idea of what specific environment variables you'd want to put in Cargo.toml and not elsewhere? It seems odd to have cargo pass per-project specific environment variables.

[TyOverby]

I'd like to use environment variables to tell my build script what libraries to build. I could see them being used to configure almost any project that has a build script generating native code.

[alexcrichton]

I'm not understanding the cargo-specific functionality you want here. Why would cargo pass different environment variables than, for example, make?

[TyOverby]

I'd want the users of my library to be able to set environment variables for my projects via Cargo.

Different libraries would have different environment variables used in their build scripts, so I don't see the reason to have them set for everything.

[TyOverby]

Another use case would be to inform a library that it should expect a dependency to be either statically or dynamically linked.

Right now, (as far as I understand), if a library uses #[link(name="foo", kind="dylib")], then there is no way to provide that library statically or vice versa.

[wycats]

Right now, (as far as I understand), if a library uses #[link(name="foo", kind="dylib")], then there is no way to provide that library statically or vice versa.

@alexcrichton and I are planning on solving this problem through a syntax extension. More to come!

[alexcrichton]

I've started working on said syntax extension here: https://github.com/alexcrichton/link-config

[ccll]

I found a use case, the rust-ffmpeg-sys has a custom build.rs which allows you to pass a environment variable 'FFMPEG_DIR' to specify the path to the pre-compiled header/lib of FFMPEG.
So when my project depends on 'rust-ffmpeg-sys', it's better to allow the developer define the env var 'FFMPEG_DIR' directly in Cargo.toml, instead of define it outside of Cargo ecosystem.
Does that sound legitimate?

[alexcrichton]

@ccll note that this is a super old issue, dependencies today can pass env vars to each other

[ccll]

@alexcrichton Thanks for the tip, but it doesn't look like what I want.

What I want is to set env vars for libfoo from libbar's config/manifest/buildscript, not the other way around, while I have control over libbar, but not libfoo. Also the env var name is distorted a bit automatically.
Is there any way to pass arbitrarily named env vars to any upstream dependencies (not necessarily immediate ones)?

[alexcrichton]

Correct yeah, that feature is covered by #3544

[ccll]

@alexcrichton I'm afraid it's still not quite the same feature.
What DEP_name_key does: down stream <-- set env <-- upstream
What I want: down stream --> set env --> upstream (to control the building behavior of upstream lib)

#3544 only eliminate the mandatory requirements on 'links' key, but still not solving the control flow direction, right? Am I correct on understanding DEP_name_key and #3544 ?

[alexcrichton]

@ccll functionality like that is typically exposed through features on crates, rather than programmatic access to env vars I believe.

[ccll]

@alexcrichton 'feature' works like a Boolean flag, but sometimes a String value is needed.
In the rust-ffmpeg-sys package, the package needs to know where to find the pre-built binaries and header files of FFMpeg, so the down-stream application code who uses the package needs to fill a env var 'FFMPEG_DIR' to tell it.

I think this is a very valid use case, especially in code involving FFI with existing C library.

[alexcrichton]

Ah yes that's currently not supported, but if you'd like to open an issue that'd be great!

[ccll]

@alexcrichton How about re-opening this issue? No?

[alexcrichton]

Mind opening a new one? This one's got a fair bit of semi-unlreated discussion now unfortunately :(

[ccll]

@alexcrichton Sure, moved to #4121 .