config.toml support [env] with [env.<cfg>]

[eric5f3759df]

Problem

some build need arch assotiated targe environment var. like rusty_v8 RUSTY_V8_ARCHIVE, so it's usefull for [env] supporting multi arch.

Proposed Solution

No response

Notes

No response

[weihanglo]

I guess cargo maintainers here possibly have little knowledge about V8 and Deno stuff. It would be great if you can provide more contexts, such like

• What exactly you're trying to resolve. A concrete example and links are great.
• Why the feature should be built-in Cargo.
• What the current solution/workaround looks like without this feature.

This would help not only maintainers but other random contributors to come up with better ideas. 😁

[Gaubee]

eg:

[env]
RUSTY_V8_ARCHIVE = { value = "assets/rusty_v8_mirror/v0.42.0/librusty_v8_release_aarch64-apple-darwin.a", relative = true }

[env.'cfg(target_os="android")']
RUSTY_V8_ARCHIVE = { value = "assets/rusty_v8_mirror/v0.42.0/librusty_v8_release_aarch64-linux-android.a", relative = true }

[MatrixDev]

I have the same problem but with openssl crate. We use prebuilt versions on openssl libs and different platforms/architectures have different folders.

So ideally I'd need something like this:

[env.'cfg(target_os = "macos")']
OPENSSL_STATIC = "1"
OPENSSL_DIR = { value = "../PrecompiledLibs/MacOS/OpenSSL/openssl-1.1.1l/release", relative = true }

[env.'cfg(target = "aarch64-linux-android")']
OPENSSL_STATIC = "1"
OPENSSL_DIR = { value = "../PrecompiledLibs/Android/OpenSSL/openssl-1.1.1l/release", relative = true }

# etc for windows and so on

[nmittler]

Similar issue here using BoringSSL ... I wanted to set environment variables differently for each target platform. Details here: #11385

[MatrixDev]

IMHO it would be much much better if we could just setup all these configs (including most of the cargo.toml) from the rs script (similar to what gradle does). This would simplify non-trivial configuration so much....

Because currently instead of "everything is rust" it is "everything is rust hidden behind toml and shell scripts" :(

[weihanglo]

if we could just setup all these configs…

For configuring environment variables, it's available today in build script with cargo:rustc-env=VAR=VALUE.

[MatrixDev]

@weihanglo, correct me if I'm wrong, but does it propagate to the libraries before their build.rs is executed?

[oblique]

@weihanglo Not really. This does not propagate to dependencies, so you can not just define OPENSSL_DIR from a build.rs.

[weihanglo]

THank you all. That is absolutely the limitation of build script today. Configuration is the current way to deal with that.

[MatrixDev]

@weihanglo, you can't deal with that with configuration, because configuration doesn't accept cfg params. please read my comment above from 28 days ago.

[weihanglo]

Sorry for not being clear. I didn't mean Cargo already support the feature described in this issue.

Let me summarize:

• Build script can set environment variables but only for the crate it associates with.
• Configuration can set environment variables for all rustc invocations but cannot differentiate cfg(…).

[nmittler]

@weihanglo makes sense. Do we have a path forward on this then?