-
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
Apply RUSTFLAGS arguments to rustc builds #2241
Conversation
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
Cargo may want to start tracking at a finer grain of why dependencies are being compiled the way they are. For example if a plugin has a dependency then the dependency will be compiled for the host architecture, but it'll have RUSTFLAGS applied to it even when the plugin doesn't. I would personally expect that the entire subgraphs of dependencies only used by plugins wouldn't get RUSTFLAGS treatment. Also, could this have a few acceptance tests as well? e.g. fails-to-compile unless RUSTFLAGS is parsed properly. |
I'll try to figure out how to propagate the plugin-ness to dependencies. re tests there is no error case in cargo's parsing of RUSTFLAGS. It only splits on space. Are there other tests you would like to see? |
I've got a patch that makes plugin deps not use RUSTFLAGS, but have discovered the build scripts have this same problem. |
It may actually be easier to just check That does mean that plugins and build scripts will get custom flags for a vanilla |
|
One other test I thought of recently to add is to ensure that changing |
@alexcrichton I updated the patch to make the logic much simpler. What I've got is:
This doesn't seem to capture your "it would also apply to Kind::Host if host == target" suggestion, but still all my test cases pass. Can you think of a test case that requires your suggested rule? I'll look at the recompilation and parsing matters now. |
Looks good to me! The recompilation will probably come about by modifying this structure . |
522db58
to
86acbc8
Compare
@alexcrichton I've added a patch to recompile when RUSTFLAGS changes. @Zoxc I'm not sure how to make RUSTFLAGS support spaces. I looked for precedent with CFLAGS and couldn't find it. Simple escaping with |
@@ -342,6 +351,7 @@ fn calculate<'a, 'cfg>(cx: &mut Context<'a, 'cfg>, unit: &Unit<'a>) | |||
deps: deps, | |||
local: local, | |||
memoized_hash: Mutex::new(None), | |||
rustflags: env::var("RUSTFLAGS").ok(), |
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 use the methods on the context instead? That way if you use RUSTFLAGS
with --target
you won't recompile any build scripts or plugins (as they're not affected by this env var anyway)
Could you also add a test for if |
@brson Maybe Pascal style escaping with |
I recommend shell-like quoting (e.g. bash If no semantics attached to |
☔ The latest upstream changes (presumably #2406) made this pull request unmergeable. Please resolve the merge conflicts. |
I've added another commit that also draws rustflags from the config file according to the following scheme:
All are lists, so argument lists with spaces work. None of these allow extra flags to be passed to build scripts and plugins when Edit: it's important to note that because the config options are lists, there aren't corresponding |
|
||
// First try RUSTFLAGS from the environment | ||
if let Some(a) = env::var("RUSTFLAGS").ok() { | ||
let args = a.split(" ").map(str::trim).map(str::to_string); |
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.
This may want a filter_map
for "not empty" for environment variables like " -l foo --sysroot bar"
Looks like some tests on travis are failing, but they probably just need a I'm curious what the difference between |
This passes RUSTFLAGS to rustc builds for the target architecture. We don't want to pass the RUSTFLAGS args to multiple architectures because they may contain architecture-specific flags. Ideally, the scheme we would use would treat plugins and build scripts - which may not be for the target architecture - consistently. Unfortunately it's quite difficult in the current Cargo architecture to seperately identify build scripts, plugins and their dependencies from code used by the target. So the scheme here is very simple: 1) If --target is not specified, RUSTFLAGS applies to all builds. 2) If --target is specified, RUSTFLAGS only applies to builds with the Kind::Target target kind, which indicates build units derived from the requested --target. Closes rust-lang#2112
They are almost the same. The difference is that |
I've removed the |
`build.rustflags` is treated exactly like `RUSTFLAGS`. It is a list, so argument lists with spaces work. `RUSTFLAGS` takes precedent, then `build.rustflags`.
I did have to |
This was the build error
|
⌛ Testing commit 2f01868 with merge 9208212... |
@bors: retry force clean |
Apply RUSTFLAGS arguments to rustc builds Cargo will use RUSTFLAGS for building everything that is not a build script or plugin. It does not apply to these targets because they may be for a different platform that 'normal' builds. Closes #2112
☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
Cargo will use RUSTFLAGS for building everything that is not a build script
or plugin. It does not apply to these targets because they may be for
a different platform that 'normal' builds.
Closes #2112