-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow cargo:rustc-env in build scripts #3929
Conversation
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/cargo/ops/cargo_rustc/mod.rs
Outdated
build_state: &BuildMap, | ||
build_scripts: &BuildScripts, | ||
current_id: &PackageId) -> CargoResult<()> { | ||
for key in build_scripts.to_link.iter() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this needs to be a loop, it can just be using build_state.get(current_id)
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
"#) | ||
.file("src/main.rs", r#" | ||
const FOO: &'static str = env!("FOO"); | ||
fn main() {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this assert the right value of FOO
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
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 |
cc @matklad, @carols10cents, @wycats, @brson, an upcoming feature in Cargo! |
@Xion |
Looks great! It needs to be documented though :) |
☔ The latest upstream changes (presumably #3974) made this pull request unmergeable. Please resolve the merge conflicts. |
ping @Xion, would you be willing to rebase and/or add docs? |
Sorry, I've been busy with onboarding at a new job. I'll try to get to it this weekend. |
No worries! Let me know if you run out of time for this and I'd be happy to take it over |
"#) | ||
.file("src/main.rs", r#" | ||
const FOO: &'static str = env!("FOO"); | ||
fn main() {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
src/cargo/ops/cargo_rustc/mod.rs
Outdated
build_state: &BuildMap, | ||
build_scripts: &BuildScripts, | ||
current_id: &PackageId) -> CargoResult<()> { | ||
for key in build_scripts.to_link.iter() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
tests/build-script.rs
Outdated
} | ||
|
||
#[test] | ||
fn env_test() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
As for namespacing, what prefix would not clash with any of the tooling? I was thinking about 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
src/cargo/ops/cargo_rustc/mod.rs
Outdated
build_state: &BuildMap, | ||
_: &BuildScripts, | ||
current_id: &PackageId) -> CargoResult<()> { | ||
let key = (current_id.clone(), Kind::Host); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, so that's what host vs target means. Makes sense! Fixed.
src/cargo/ops/cargo_rustc/mod.rs
Outdated
// been put there by one of the `build_scripts`) to the command provided. | ||
fn add_custom_env(rustc: &mut ProcessBuilder, | ||
build_state: &BuildMap, | ||
_: &BuildScripts, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah feel free to just remvoe this parameter if it's not used.
I've fixed the problem the test for |
📌 Commit 8e6ffa5 has been approved by |
⌛ Testing commit 8e6ffa5 with merge 6709508... |
💔 Test failed - status-travis |
@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>
.
|
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.
☀️ Test successful - status-appveyor, status-travis |
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 toenv!()
-friendly env. vars that rustc is run with.