bazelbuild / bazelbuild/rules_rust

Set the same env vars as cargo both when invoking rustc and when invoking a cargo_build_script

Open
#661 2 comments 1 reaction 0 assignees View on GitHub
cargo enhancement needs-triage
Dominant language
Starlark
Stars
843
Forks
651
Avg merge
2d 18h
Merged PRs (30d)
15

Description

Cargo sets [this list](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates) of env vars when either invoking rustc, or `cargo run`ing or `cargo test`ing a binary. We should be setting them all when we invoke `rustc`.

Cargo additionally sets [this list](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts) of env vars when running (not when compiling) a build script. We should be setting them all when we invoke a build script. We should _also_ be setting all of the `rustc` env vars when we invoke a build script.

Currently we have two lists of env vars:

This list is used for when we invoke `rustc`: https://github.com/bazelbuild/rules_rust/blob/e744b93f5e6fa21b2c4ee2e49e984e7402df9e46/rust/private/rustc.bzl#L57-L85

This list is used when we invoke an already-compiled build-script (note that we use the above list when _compiling_ the build script): https://github.com/bazelbuild/rules_rust/blob/e744b93f5e6fa21b2c4ee2e49e984e7402df9e46/cargo/cargo_build_script.bzl#L79-L132

Both of these lists are currently incomplete, as we've generally added stuff as-needed. Additionally, the `rustc_env` list contains some vars which should actually only be in the build_script list (e.g. `CARGO_CFG_TARGET_ARCH` and `CARGO_CFG_TARGET_OS`).

We should:
1. Make the build script env vars be a superset of the rustc ones, by calling `_get_rustc_env` from `_build_script_impl`. This will both help keep the lists in sync, and avoid duplicating things like the processing of version numbers.
2. Move any build_script-specific env vars out of `_get_rustc_env`
3. (Optional): Add more env vars pro-actively, rather than reactively when someone finds some third-party code doesn't build.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.