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

Merged
merged 3 commits into from Mar 17, 2016

Conversation

Projects
None yet
8 participants
@brson
Contributor

brson commented Dec 22, 2015

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

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Dec 22, 2015

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

rust-highfive commented Dec 22, 2015

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

@brson

This comment has been minimized.

Show comment
Hide comment
@brson
Contributor

brson commented Dec 22, 2015

@rust-highfive rust-highfive assigned alexcrichton and unassigned huonw Dec 22, 2015

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Dec 23, 2015

Member

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.

Member

alexcrichton commented Dec 23, 2015

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.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Dec 28, 2015

Contributor

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?

Contributor

brson commented Dec 28, 2015

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?

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Dec 28, 2015

Contributor

I've got a patch that makes plugin deps not use RUSTFLAGS, but have discovered the build scripts have this same problem.

Contributor

brson commented Dec 28, 2015

I've got a patch that makes plugin deps not use RUSTFLAGS, but have discovered the build scripts have this same problem.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jan 11, 2016

Member

It may actually be easier to just check kind to see whether the custom flags apply. Custom flags would apply to Kind::Target unconditionally and then it would also apply to Kind::Host if host == target.

That does mean that plugins and build scripts will get custom flags for a vanilla cargo build, but that's probably ok?

Member

alexcrichton commented Jan 11, 2016

It may actually be easier to just check kind to see whether the custom flags apply. Custom flags would apply to Kind::Target unconditionally and then it would also apply to Kind::Host if host == target.

That does mean that plugins and build scripts will get custom flags for a vanilla cargo build, but that's probably ok?

@Zoxc

This comment has been minimized.

Show comment
Hide comment
@Zoxc

Zoxc Jan 16, 2016

RUSTFLAGS should allow passing command line arguments which include spaces. I want to use this to pass --sysroot to rustc.

Zoxc commented Jan 16, 2016

RUSTFLAGS should allow passing command line arguments which include spaces. I want to use this to pass --sysroot to rustc.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jan 27, 2016

Member

One other test I thought of recently to add is to ensure that changing RUSTFLAGS will trigger recompliations.

Member

alexcrichton commented Jan 27, 2016

One other test I thought of recently to add is to ensure that changing RUSTFLAGS will trigger recompliations.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Feb 17, 2016

Contributor

@alexcrichton I updated the patch to make the logic much simpler. What I've got is:

  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.

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.

Contributor

brson commented Feb 17, 2016

@alexcrichton I updated the patch to make the logic much simpler. What I've got is:

  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.

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.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 17, 2016

Member

Looks good to me! The recompilation will probably come about by modifying this structure .

Member

alexcrichton commented Feb 17, 2016

Looks good to me! The recompilation will probably come about by modifying this structure .

@brson brson added the relnotes label Feb 17, 2016

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Feb 17, 2016

Contributor

@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 \ would make passing windows paths pretty terrible - everyone would need to know to escape RUSTFLAGS all the time.

Contributor

brson commented Feb 17, 2016

@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 \ would make passing windows paths pretty terrible - everyone would need to know to escape RUSTFLAGS all the time.

Show outdated Hide outdated src/cargo/ops/cargo_rustc/fingerprint.rs
@@ -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(),

This comment has been minimized.

@alexcrichton

alexcrichton Feb 17, 2016

Member

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)

@alexcrichton

alexcrichton Feb 17, 2016

Member

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)

Show outdated Hide outdated src/cargo/ops/cargo_rustc/fingerprint.rs
@@ -421,6 +431,7 @@ pub fn prepare_build_cmd<'a, 'cfg>(cx: &mut Context<'a, 'cfg>, unit: &Unit<'a>)
deps: Vec::new(),
local: local,
memoized_hash: Mutex::new(None),
rustflags: env::var("RUSTFLAGS").ok(),

This comment has been minimized.

@alexcrichton

alexcrichton Feb 17, 2016

Member

This is fine to leave as empty because running the build script itself (what this fingerprint is for) doesn't actually depend on RUSTFLAGS. Compilation of the build script should be covered by the fingerprint above I believe

@alexcrichton

alexcrichton Feb 17, 2016

Member

This is fine to leave as empty because running the build script itself (what this fingerprint is for) doesn't actually depend on RUSTFLAGS. Compilation of the build script should be covered by the fingerprint above I believe

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 17, 2016

Member

Could you also add a test for if RUSTFLAGS changes that a rebuild happens? Also if RUSTFLAGS doesn't change a rebuild doesn't spuriously happen

Member

alexcrichton commented Feb 17, 2016

Could you also add a test for if RUSTFLAGS changes that a rebuild happens? Also if RUSTFLAGS doesn't change a rebuild doesn't spuriously happen

@Zoxc

This comment has been minimized.

Show comment
Hide comment
@Zoxc

Zoxc Feb 17, 2016

@brson Maybe Pascal style escaping with " is better? or use another escape charater than \

Zoxc commented Feb 17, 2016

@brson Maybe Pascal style escaping with " is better? or use another escape charater than \

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Feb 17, 2016

Member

I recommend shell-like quoting (e.g. bash "..." and '...'), with no $ or other such special cases.

If no semantics attached to \ are desired, then you can have both "..." and '...', with the former obeying the same simple rules as the latter.
You can then escape a'b by using "a'b" and x"y by using 'x"y', and it's still a proper subset of bash quote handling.

Member

eddyb commented Feb 17, 2016

I recommend shell-like quoting (e.g. bash "..." and '...'), with no $ or other such special cases.

If no semantics attached to \ are desired, then you can have both "..." and '...', with the former obeying the same simple rules as the latter.
You can then escape a'b by using "a'b" and x"y by using 'x"y', and it's still a proper subset of bash quote handling.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 17, 2016

Member

I'd personally prefer to avoid escaping altogether somehow if possible. I don't really want to start adding a bash string parser to both Cargo and the compiler eventually. I jokingly mentioned on IRC that we could do something like RUSTFLAGS1, RUSTFLAGS2, etc, but that may actually be somewhat plausible. We could have something that looks like:

  • The environment variable RUSTFLAGS is read, split on spaces, and used.
  • The environment variable RUSTFLAGS<n> is read (where <n> starts as 1). This isn't split on spaces and it's just used as-is.
  • Increment <n> until the environment variable doesn't exist.

Or... well... ok now that I write that down it sounds a little too crazy to implement.

Another alternative, support build.rustflags (which actually may want to be supported anyway) in .cargo/config like:

[build]
rustflags = ["-foo", "-bar", "-baz"]

And that would at least solve all problems!

Member

alexcrichton commented Feb 17, 2016

I'd personally prefer to avoid escaping altogether somehow if possible. I don't really want to start adding a bash string parser to both Cargo and the compiler eventually. I jokingly mentioned on IRC that we could do something like RUSTFLAGS1, RUSTFLAGS2, etc, but that may actually be somewhat plausible. We could have something that looks like:

  • The environment variable RUSTFLAGS is read, split on spaces, and used.
  • The environment variable RUSTFLAGS<n> is read (where <n> starts as 1). This isn't split on spaces and it's just used as-is.
  • Increment <n> until the environment variable doesn't exist.

Or... well... ok now that I write that down it sounds a little too crazy to implement.

Another alternative, support build.rustflags (which actually may want to be supported anyway) in .cargo/config like:

[build]
rustflags = ["-foo", "-bar", "-baz"]

And that would at least solve all problems!

@japaric

This comment has been minimized.

Show comment
Hide comment
@japaric

japaric Feb 17, 2016

Member

Another alternative, support build.rustflags

Yes, please. Also make it a per profile setting.

Member

japaric commented Feb 17, 2016

Another alternative, support build.rustflags

Yes, please. Also make it a per profile setting.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Feb 18, 2016

Contributor

I've addressed @alexcrichton's comments. Still no escaping.

Contributor

brson commented Feb 18, 2016

I've addressed @alexcrichton's comments. Still no escaping.

Show outdated Hide outdated src/cargo/ops/cargo_rustc/fingerprint.rs
@@ -421,6 +430,7 @@ pub fn prepare_build_cmd<'a, 'cfg>(cx: &mut Context<'a, 'cfg>, unit: &Unit<'a>)
deps: Vec::new(),
local: local,
memoized_hash: Mutex::new(None),
rustflags: cx.rustflags_args(unit),

This comment has been minimized.

@alexcrichton

alexcrichton Feb 18, 2016

Member

This I think can just be Vec::new() because the build script executing won't depend on RUSTFLAGS, just the compilation (handled above)

@alexcrichton

alexcrichton Feb 18, 2016

Member

This I think can just be Vec::new() because the build script executing won't depend on RUSTFLAGS, just the compilation (handled above)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 18, 2016

Member

So I'm personally ok with only splitting on spaces, it's consistent with what the compiler does with, e.g. -C link-args. That being said it does have downsides, but I suspect that the .cargo/config option would solve that problem because we have TOML at our backs as a proper encoding.

@brson could you add support for reading the build.rustflags configuration as well? If both build.rustflags and RUSTFLAGS is set we could either concatenate or override with RUSTFLAGS, and I'm somewhat tempted to concatenate for now? The support should be relatively easy to add as there's helper methods on Config to read out configuration values with all the error handling taken care of.

Member

alexcrichton commented Feb 18, 2016

So I'm personally ok with only splitting on spaces, it's consistent with what the compiler does with, e.g. -C link-args. That being said it does have downsides, but I suspect that the .cargo/config option would solve that problem because we have TOML at our backs as a proper encoding.

@brson could you add support for reading the build.rustflags configuration as well? If both build.rustflags and RUSTFLAGS is set we could either concatenate or override with RUSTFLAGS, and I'm somewhat tempted to concatenate for now? The support should be relatively easy to add as there's helper methods on Config to read out configuration values with all the error handling taken care of.

@Zoxc

This comment has been minimized.

Show comment
Hide comment
@Zoxc

Zoxc Feb 23, 2016

I really don't like having to create a file to pass command line arguments, especially if .cargo/config could be checked into a VCS.

Zoxc commented Feb 23, 2016

I really don't like having to create a file to pass command line arguments, especially if .cargo/config could be checked into a VCS.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Feb 23, 2016

Member

I don't really want to start adding a bash string parser to both Cargo and the compiler eventually.

In its defense, if you don't care about \ special cases, just quotes, "parsing" such a string is trivial.

Member

eddyb commented Feb 23, 2016

I don't really want to start adding a bash string parser to both Cargo and the compiler eventually.

In its defense, if you don't care about \ special cases, just quotes, "parsing" such a string is trivial.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 26, 2016

Member

I had a chance to chat about this with @wycats today and some thoughts we had were:

  • This seems like a well motivated feature, and we definitely want .cargo/config configuration for it as well.
  • In terms of environment variables, this interacts with #2398. That PR doesn't currently add support to read a list of strings from an environment variable (we'd have to invent an encoding), which is what we would want this configuration option to be.
  • On possible course of action is to have RUSTFLAGS be space-separated and then CARGO_BUILD_RUSTFLAGS could be whatever encoding scheme we come up with for a list of strings. (in the long run)
Member

alexcrichton commented Feb 26, 2016

I had a chance to chat about this with @wycats today and some thoughts we had were:

  • This seems like a well motivated feature, and we definitely want .cargo/config configuration for it as well.
  • In terms of environment variables, this interacts with #2398. That PR doesn't currently add support to read a list of strings from an environment variable (we'd have to invent an encoding), which is what we would want this configuration option to be.
  • On possible course of action is to have RUSTFLAGS be space-separated and then CARGO_BUILD_RUSTFLAGS could be whatever encoding scheme we come up with for a list of strings. (in the long run)
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Feb 29, 2016

Contributor

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

Contributor

bors commented Feb 29, 2016

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

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 4, 2016

Contributor

I've added another commit that also draws rustflags from the config file according to the following scheme:

build.rustflags is treated exactly like RUSTFLAGS.

target.rustflags only applies when --target is not specified.

target.$triple.rustflags only applies when `--target is
specified and the target matches.

RUSTFLAGS takes precedent, then build.rustflags, then target.

All are lists, so argument lists with spaces work. None of these allow extra flags to be passed to build scripts and plugins when --target is specified. We probably shouldn't land all these options.

Edit: it's important to note that because the config options are lists, there aren't corresponding CARGO_* env vars, only RUSTFLAGS.

Contributor

brson commented Mar 4, 2016

I've added another commit that also draws rustflags from the config file according to the following scheme:

build.rustflags is treated exactly like RUSTFLAGS.

target.rustflags only applies when --target is not specified.

target.$triple.rustflags only applies when `--target is
specified and the target matches.

RUSTFLAGS takes precedent, then build.rustflags, then target.

All are lists, so argument lists with spaces work. None of these allow extra flags to be passed to build scripts and plugins when --target is specified. We probably shouldn't land all these options.

Edit: it's important to note that because the config options are lists, there aren't corresponding CARGO_* env vars, only RUSTFLAGS.

Show outdated Hide outdated src/cargo/ops/cargo_rustc/context.rs
// 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);

This comment has been minimized.

@alexcrichton

alexcrichton Mar 7, 2016

Member

This may want a filter_map for "not empty" for environment variables like " -l foo --sysroot bar"

@alexcrichton

alexcrichton Mar 7, 2016

Member

This may want a filter_map for "not empty" for environment variables like " -l foo --sysroot bar"

Show outdated Hide outdated Cargo.lock
@@ -19,11 +19,11 @@ dependencies = [
"libc 0.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
"libgit2-sys 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)",
"num_cpus 0.2.10 (registry+https://github.com/rust-lang/crates.io-index)",
"regex 0.1.48 (registry+https://github.com/rust-lang/crates.io-index)",
"num_cpus 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",

This comment has been minimized.

@alexcrichton

alexcrichton Mar 7, 2016

Member

Out of curiosity, was this updated required to get the patch to land? Or was this just a routine updated?

@alexcrichton

alexcrichton Mar 7, 2016

Member

Out of curiosity, was this updated required to get the patch to land? Or was this just a routine updated?

This comment has been minimized.

@brson

brson Mar 16, 2016

Contributor

I don't recall.

@brson

brson Mar 16, 2016

Contributor

I don't recall.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 7, 2016

Member

Looks like some tests on travis are failing, but they probably just need a if !::is_nightly() { return } gate as they're using unstable features.

I'm curious what the difference between build.rustflags and target.rustflags are, they seem roughly equivalent right? Otherwise target.$triple.rustflags seems somewhat reasonable to me, but I'd also be fine starting out with just build.rustflags and RUSTFLAGS.

Member

alexcrichton commented Mar 7, 2016

Looks like some tests on travis are failing, but they probably just need a if !::is_nightly() { return } gate as they're using unstable features.

I'm curious what the difference between build.rustflags and target.rustflags are, they seem roughly equivalent right? Otherwise target.$triple.rustflags seems somewhat reasonable to me, but I'd also be fine starting out with just build.rustflags and RUSTFLAGS.

brson added some commits Feb 17, 2016

Apply RUSTFLAGS env var to rustc builds
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 #2112
@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 16, 2016

Contributor

I'm curious what the difference between build.rustflags and target.rustflags are, they seem roughly equivalent right

They are almost the same. The difference is that build.rustflags applies regardless of whether --target is specified whereas target.rustflags only applies when --target is not specified.

Contributor

brson commented Mar 16, 2016

I'm curious what the difference between build.rustflags and target.rustflags are, they seem roughly equivalent right

They are almost the same. The difference is that build.rustflags applies regardless of whether --target is specified whereas target.rustflags only applies when --target is not specified.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 16, 2016

Contributor

I've removed the target.* options and filtered out empty strings.

Contributor

brson commented Mar 16, 2016

I've removed the target.* options and filtered out empty strings.

Add rustflags support to config files
`build.rustflags` is treated exactly like `RUSTFLAGS`.

It is a list, so argument lists with spaces work.

`RUSTFLAGS` takes precedent, then `build.rustflags`.
@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 16, 2016

Contributor

I did have to cargo update again today to get around a build error.

Contributor

brson commented Mar 16, 2016

I did have to cargo update again today to get around a build error.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 16, 2016

Contributor

This was the build error

/home/brian/.cargo/registry/src/github.com-88ac128001ac3a9a/libgit2-sys-0.4.0/lib.rs:539:9: 539:30 error: unresolved import `git_status_show_t::*`. Not a modu
le `git_status_show_t` [E0432]
/home/brian/.cargo/registry/src/github.com-88ac128001ac3a9a/libgit2-sys-0.4.0/lib.rs:539 pub use git_status_show_t::*;
                                                                                                 ^~~~~~~~~~~~~~~~~~~~~
/home/brian/.cargo/registry/src/github.com-88ac128001ac3a9a/libgit2-sys-0.4.0/lib.rs:539:9: 539:30 help: run `rustc --explain E0432` to see a detailed explana
tion
Contributor

brson commented Mar 16, 2016

This was the build error

/home/brian/.cargo/registry/src/github.com-88ac128001ac3a9a/libgit2-sys-0.4.0/lib.rs:539:9: 539:30 error: unresolved import `git_status_show_t::*`. Not a modu
le `git_status_show_t` [E0432]
/home/brian/.cargo/registry/src/github.com-88ac128001ac3a9a/libgit2-sys-0.4.0/lib.rs:539 pub use git_status_show_t::*;
                                                                                                 ^~~~~~~~~~~~~~~~~~~~~
/home/brian/.cargo/registry/src/github.com-88ac128001ac3a9a/libgit2-sys-0.4.0/lib.rs:539:9: 539:30 help: run `rustc --explain E0432` to see a detailed explana
tion
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 16, 2016

Member

@bors: r+ 2f01868

I am excite!

Member

alexcrichton commented Mar 16, 2016

@bors: r+ 2f01868

I am excite!

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 16, 2016

Contributor

⌛️ Testing commit 2f01868 with merge 9208212...

Contributor

bors commented Mar 16, 2016

⌛️ Testing commit 2f01868 with merge 9208212...

bors added a commit that referenced this pull request Mar 16, 2016

Auto merge of #2241 - brson:rustflags, r=alexcrichton
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
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 17, 2016

Member

@bors: retry force clean

Member

alexcrichton commented Mar 17, 2016

@bors: retry force clean

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 17, 2016

Contributor

⌛️ Testing commit 2f01868 with merge 8c60ada...

Contributor

bors commented Mar 17, 2016

⌛️ Testing commit 2f01868 with merge 8c60ada...

bors added a commit that referenced this pull request Mar 17, 2016

Auto merge of #2241 - brson:rustflags, r=alexcrichton
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
@bors

This comment has been minimized.

Show comment
Hide comment

@bors bors merged commit 2f01868 into rust-lang:master Mar 17, 2016

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@alexcrichton alexcrichton deleted the brson:rustflags branch Apr 25, 2016

@pnkfelix pnkfelix referenced this pull request Jan 15, 2018

Closed

Bug optimization #47410

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment