Allow cargo:rustc-env in build scripts by Xion · Pull Request #3929 · rust-lang/cargo

Xion · 2017-04-17T18:55:40Z

This is an attempt to address issue #2875. Basically, I'm trying to allow build scripts to producecargo:rustc-env=FOO=foo lines in their output. These are then translated to env!()-friendly env. vars that rustc is run with.

rust-highfive · 2017-04-17T18:55:53Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

alexcrichton

Looking good to me, thanks @Xion!

I wonder if we want to maybe pursue namespacing the env vars though? Righw now cargo exports env vars as CARGO_* and we may wish to scope the custom env vars here to ensure they don't clash with future significant env vars and such.

alexcrichton · 2017-04-20T17:58:51Z

I don't think this needs to be a loop, it can just be using build_state.get(current_id), right?

current_id is just a PackageId, and to key into BuildMap I also a cargo_rustc::Kind which I'm not entirely clear about the purpose of. I picked Kind::Host following the other similar usages and it seems to work no worse than the previous version.

alexcrichton · 2017-04-20T17:59:15Z

Could this assert the right value of FOO as well?

alexcrichton · 2017-04-20T18:03:52Z

Note that another use case in #2875 is to export git information which I think Cargo should just do by default.

In any case I feel like this is a totally fine feature to have, it's certainly more ergonomic than using include!!

alexcrichton · 2017-04-20T18:04:15Z

cc @matklad, @carols10cents, @wycats, @brson, an upcoming feature in Cargo!

petrochenkov · 2017-04-20T20:21:12Z

@Xion
Build script overrides need to be updated as well.

matklad · 2017-04-21T09:32:56Z

Looks great! It needs to be documented though :)

bors · 2017-05-08T22:40:08Z

☔ The latest upstream changes (presumably #3974) made this pull request unmergeable. Please resolve the merge conflicts.

alexcrichton · 2017-05-11T20:57:45Z

ping @Xion, would you be willing to rebase and/or add docs?

Xion · 2017-05-12T08:42:05Z

Sorry, I've been busy with onboarding at a new job. I'll try to get to it this weekend.

alexcrichton · 2017-05-12T14:13:40Z

No worries! Let me know if you run out of time for this and I'd be happy to take it over

Xion · 2017-05-12T20:51:27Z

Xion · 2017-05-12T20:51:33Z

current_id is just a PackageId, and to key into BuildMap I also a cargo_rustc::Kind which I'm not entirely clear about the purpose of. I picked Kind::Host following the other similar usages and it seems to work no worse than the previous version.

Xion · 2017-05-12T20:53:59Z

The problem is that this test still fails at the build step (with FOO variable not being defined). There is apparently something more that needs to be done to carry the variables if the build scripts is invoked for a crate as dependency for the test crate.

Xion · 2017-05-12T21:05:21Z

As for namespacing, what prefix would not clash with any of the tooling? I was thinking about RUSTC_ENV_ to match the script output, or CARGO_ENV_ to call dibs on that one already.

On the other hand, I'm not sure such prefixing is necessary nor desirable. Since the values for the env vars are purely in the user's discretion, the names should be too. There may even be some valid use cases for shadowing the CARGO_ variables -- which the user can already do by invoking CARGO_FOO=x cargo rustc -- so I wouldn't preclude that either.

alexcrichton

Yeah I think you're right in that we may wish to eschew the prefix, that sounds ok to me.

I think there's some tests failing here related to rustdoc as well? Could you also add tests that execute cargo doc to ensure that works as well?

alexcrichton · 2017-05-12T22:55:26Z

+                      build_state: &BuildMap,
+                      _: &BuildScripts,
+                      current_id: &PackageId) -> CargoResult<()> {
+        let key = (current_id.clone(), Kind::Host);


Ah yes here you'll want to pass in a kind instead of just picking Kind::Host, which I believe will break cross-compiled builds. Typically most rules have unit.kind which can be ferried to this locaion.

Oh, so that's what host vs target means. Makes sense! Fixed.

alexcrichton · 2017-05-12T22:55:34Z

+    // been put there by one of the `build_scripts`) to the command provided.
+    fn add_custom_env(rustc: &mut ProcessBuilder,
+                      build_state: &BuildMap,
+                      _: &BuildScripts,


Ah feel free to just remvoe this parameter if it's not used.

Xion · 2017-05-13T16:03:36Z

I've fixed the problem the test for cargo test, and also added one for rustdoc. Documentation is also included.

alexcrichton · 2017-05-15T14:40:14Z

@bors: r+

Looks great to me, thanks so much for tackling this @Xion!

bors · 2017-05-15T14:40:16Z

📌 Commit 8e6ffa5 has been approved by alexcrichton

bors · 2017-05-15T15:34:28Z

⌛ Testing commit 8e6ffa5 with merge 6709508...

bors · 2017-05-15T16:12:06Z

💔 Test failed - status-travis

alexcrichton · 2017-05-15T16:25:17Z

@bors: retry

…

On Mon, May 15, 2017 at 11:12 AM, bors ***@***.***> wrote: 💔 Test failed - status-travis <https://travis-ci.org/rust-lang/cargo/builds/232480738?utm_source=github_status&utm_medium=notification> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3929 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD95BjE9TUzh7w-5PBtuqL5c7pzqLi4ks5r6HlXgaJpZM4M_cKm> .

bors · 2017-05-15T18:34:46Z

⌛ Testing commit 8e6ffa5 with merge 00af72e...

Allow cargo:rustc-env in build scripts This is an attempt to address issue #2875. Basically, I'm trying to allow build scripts to produce`cargo:rustc-env=FOO=foo` lines in their output. These are then translated to `env!()`-friendly env. vars that rustc is run with.

bors · 2017-05-15T20:28:25Z

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 00af72e to master...

rust-highfive assigned alexcrichton Apr 17, 2017

alexcrichton reviewed Apr 20, 2017

View reviewed changes

alexcrichton added the relnotes Release-note worthy label Apr 20, 2017

Xion added 2 commits May 12, 2017 20:18

Allow cargo:rustc-env in build scripts

8b744a0

Fix PR comments

f1ae9f8

Xion force-pushed the master branch from 88e9e04 to f1ae9f8 Compare May 12, 2017 20:49

Xion commented May 12, 2017

View reviewed changes

alexcrichton reviewed May 12, 2017

View reviewed changes

Xion added 2 commits May 13, 2017 16:51

Fix build script envvars for cargo test/doc

cb1e615

Document the feature

8e6ffa5

bors merged commit 8e6ffa5 into rust-lang:master May 15, 2017

durka added a commit to durka/foreman that referenced this pull request May 24, 2017

add env_var output for cargo:rustc-env (see rust-lang/cargo#3929)

794fb51

This was referenced Jun 7, 2017

Add a way to add arbitrary environment variables to invocation of rustc from build scripts #2875

Closed

Support cargo:rustc-env rustyhorde/vergen#2

Closed

jtgeibel mentioned this pull request Jul 18, 2017

Make the git SHA of the currently deployed code visible through ember-cli-app-version rust-lang/crates.io#879

Closed

6 tasks

ehuss mentioned this pull request Jan 25, 2021

Cargo set environment variables provided by build scripts randomly when running tests #9100

Closed

ehuss added this to the 1.19.0 milestone Feb 6, 2022

Uh oh!

Uh oh!

Conversation

Xion commented Apr 17, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Apr 17, 2017

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcrichton commented Apr 20, 2017

Uh oh!

alexcrichton commented Apr 20, 2017

Uh oh!

petrochenkov commented Apr 20, 2017

Uh oh!

matklad commented Apr 21, 2017

Uh oh!

bors commented May 8, 2017

Uh oh!

alexcrichton commented May 11, 2017

Uh oh!

Xion commented May 12, 2017

Uh oh!

alexcrichton commented May 12, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Xion commented May 12, 2017

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Xion commented May 13, 2017

Uh oh!

alexcrichton commented May 15, 2017

Uh oh!

bors commented May 15, 2017

Uh oh!

bors commented May 15, 2017

Uh oh!

bors commented May 15, 2017

Uh oh!

alexcrichton commented May 15, 2017 via email

Uh oh!

bors commented May 15, 2017

Uh oh!

bors commented May 15, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Xion commented Apr 17, 2017 •

edited

Loading