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?

[mikemorris]

Any update on this or a suggestion of where changes would need to be made to implement this functionality?

[Kamicosi]

As a workaround, I use a Makefile that defines the needed enivironment variables with the command. In my case, I need to choose which OpenCV libraries to link against.

# Makefile
all: test cross

test:
	OPENCV_LINK_LIBS=opencv_core,opencv_imgproc,opencv_highgui OPENCV_LINK_PATHS=/usr/local/lib/ OPENCV_INCLUDE_PATHS=/usr/local/include/opencv4/ cargo test

cross:
	OPENCV_LINK_LIBS=opencv_core,opencv_imgproc,opencv_highgui OPENCV_LINK_PATHS=/home/cendo/aarch64-unknown-linux-gnu/lib/ OPENCV_INCLUDE_PATHS=/home/cendo/aarch64-unknown-linux-gnu/include/opencv4/ cross build --target aarch64-unknown-linux-gnu

.PHONY: test cross

[Kentzo]

Another workaround:

Set the RUSTC_WRAPPER environment variable or the build.rustc-wrapper Cargo config variable to point to a custom shell script:

#!/bin/zsh

target_option_idx=${@[(Ie)--target]}

if [[ ${target_option_idx} -ne 0 ]]; then
    target_value_idx=$((target_option_idx + 1))
    target_value=$@[target_value_idx]

    if [[ "${target_value}" = "<triple>" ]]; then
        exec /usr/bin/env <TARGET_ENV_VAR>=<TARGET_ENV_VALUE> "$@"
    fi
fi

exec /usr/bin/env "$@"

[jonatino]

Another use case where this would be useful:

[env]
OPENCV_INCLUDE_PATHS= { value = "target\\vcpkg\\installed\\x64-windows-static\\include", relative = true }
OPENCV_LINK_PATHS= { value = "target\\vcpkg\\installed\\x64-windows-static\\lib", relative = true }
OPENCV_LINK_LIBS="opencv_core4,opencv_imgproc4,zlib"
OPENCV_MSVC_CRT="static"

It'd be nice to specify a target per [env] block so I can easily replace "x64-windows-static" with the current target in OPENCV_INCLUDE_PATHS and OPENCV_LINK_PATHS.

This feature would be really useful because of the limitation of build.rs not being able to be executed BEFORE any dependencies are built. In a perfect world, we get a build script which can run pre-building dependencies 😄 that is std only.

[weihanglo]

A workaround we have today: create ./cargo/my-aarch64-config.toml and run cargo build --config .cargo/my-aarch64-config.toml. It's too long to type during development, but for CI it should be sufficient.

[Trites]

A workaround we have today: create ./cargo/my-aarch64-config.toml and run cargo build --config .cargo/my-aarch64-config.toml. It's too long to type during development, but for CI it should be sufficient.

To futher shorten the command you can have a default config with alias pointing to secondary config:

.cargo/config.toml:

[alias]
build_arm = "build --config .cargo/arm_config.toml --target arm-(...)"

$ cargo build_arm