Support per-target environment variables

[nmittler]

Problem

I have a project that is using cloudflare boringssl, which is a rust wrapper around BoringSSL.

The cloudflare boringssl library offers a feature (fips) to build a FIPS-compliant version of the library. Enabling this feature will force it to build against a specific (old) version of BoringSSL that was FIPS-certified. It also requires that it be built with Clang 7.0.1, which was used in the FIPS testing. Most environments, however, will have a much more recent version of Clang, and installing Clang 7.0.1 can be difficult (e.g. osx).

To get around this problem on linux x86_64, we ship a pre-built distribution of boringssl and we use the environment variable BORING_BSSL_PATH to point the cloudflare library to our distro.

We have this environment variable set in .cargo/config.toml, but this has a couple of problems:

1. It will be used regarless of whether the fips feature is enabled.
2. It will be used by all target platforms.

Proposed Solution

Allow environment variables to be specified in .cargo/config.toml under each target. This way, we could only set the variables for linux x86_64.

For osx, we would just opt out of fips altogether. We would not set the variable in .cargo/config.toml. Then the user would disable fips by passing --no-default-features on the command line.

Alternatively, it would be even better if there way a way to set environment variables in .cargo/config.toml conditionally based on whether a feature is enabled. Not sure which option would be harder to implement.

Notes

No response

[weihanglo]

Thanks for your detailed report!

Alternatively, it would be even better if there way a way to set environment variables in .cargo/config.toml conditionally based on whether a feature is enabled. Not sure which option would be harder to implement.

There are some technical issues of supporting things like [target.cfg(feature = "myfeat")] (see #8170). Otherwise, this seems to be a duplicate of #10273. Closing this out in favour of that.

(If you think it is wrong, comment here and we'll consider reopen this 🙂)

[nmittler]

@weihanglo Thanks!