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