Build a crate with specific variables

[yaa110]

Describe the problem you are trying to solve
During the build of nginx crate, I want to let users specify the version of Nginx when they use this crate as a dependency.

Describe the solution you'd like

// build.rs of crate_a
fn main() {
    let val1 = vars!("key1");
    let val2 = vars!("key2");
}

# Cargo.toml of crate_b
[dependencies]
crate_a = { version = "0.2.0",  vars = ["key1:val1", "key2:val2"] }

[lukaslueg]

openssl-rust may demonstrate a way to do this

[Eh2406]

How do vars differ from features?

[yaa110]

vars is an array of key:value pairs. It should be used in build.rs file.

[oliver-giersch]

The lack of such a feature (or something similar) is a major pain in the rear for me currently.

I'd like to let users of my hazptr crate define some compile time parameters for performance fine tuning. Since this crate would likely only be used by other libraries, setting a global environmental variable upon invocation of cargo (e.g. env HAZPTR_SCAN_THRESHOLD=1 cargo build) is not a realistic option.

I've tried to do this through build scripts but failed, since apparently you can not affect environment variables through build scripts across crate boundaries.

[Perlmint]

I need this feature too!
In my case, My project is determining the features of the target by a combination of variables. Currently, I worked around this by using environment variables and build script. It works, but environment variables don't affect the build hash, So, even if environment variables are changed, cargo does not rebuild it. To prevent using the wrong build, I'm using different target dirs for each combination, but it wastes too many spaces and time to build the same dependencies.

Also, I'm interested in implementing this. Can I take this?

Here are more details to implement this. If there is any suggestion, comment, please.

• Define available vars & set the default value of it (Optional) in the Cargo.toml.
• Expose each vars as an environment variable to access vars in the build script.
• Update build metadata hash with specified vars.
• Add option setting vars to build command.

[yaa110]

@Perlmint

you can use the following in your build.rs main function:

println!("cargo:rerun-if-env-changed=YOUR_ENV");

[Perlmint]

@yaa110
Hmm... Before I tried to use rerun-if-env-changed, It looks not working on windows. But today, I tried this with the simple reproduction case on OSX. It works. 😂 I'll retry this on the windows later.

EDIT: There was a typo. It works well in Windows too.

[epage]

https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618 might be an option for this.

[wyatt-herkamp]

So I was thinking about this earlier. Then I saw this issue. 
Now I was thinking of it more of an expanded form of features

[features]
default = ["tls:rustls"]
[features.tls]  
options = ["native", "rustls"]  
rustls = ["actix-web/rustls-0_21", "dep:rustls", "rustls-pemfile", "lettre/tokio1-rustls-tls"]  
native-tls = ["lettre/tokio1-native-tls", "openssl", "actix-web/openssl"]  
required = true # An Option must be selected

It would be seen as more of "features with options"

cargo build --features tls:rustls

And to use them in creates

[dependencies]
my_crate = {version: "0.1.0", features = ["tls:rustls"]}

[epage]

#2980 is the issue for mutually exclusive features. The big problem with is is feature unification (if two packages set different values, what do you do?).

This is why the above proposal shifts the problem of mutually exclusive features into being "global features", bypassing unification.

[epage]

Thinking more on this, is there enough distinction from #2980 to keep this open or should we close in favor of that one?

[weihanglo]

Agree that #2980 could be a way to resolve this. Some of the use cases of this can also be fixed by #6373 (comment), e.g. cargo:rerun-if-env-changed=YOUR_ENV.

Starting from Rust 1.56, [env] is also available, but there is an unexpected behavior that rerun-if-env-changed doesn't work well with [env] table. We track it in #10358.

Close this in favor of #2980. Please let us know if we overlooked something.