Right, now, if I do RUSTFLAGS=--color=never x.py build, I get:
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
error: failed to run `rustc` to learn about target-specific information
Caused by:
process didn't exit successfully: `/home/pnkfelix/Dev/Mozilla/issue27282/rust-27282/objdir-dbgopt/build/bootstrap/debug/rustc - --crate-name ___ --print=file-names --color=never --target x86_64-unknown-linux-gnu --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 101)
--- stderr
error: Option 'color' given more than once
My initial inference here is that we are dying because rustc is getting multiple --color=never directives (and one is coming in implicitly via RUSTFLAGS
In my opinion, rustc should allow one to pass --color=never multiple times. (Arguably other combinations of --color should also be allowed.)
- Perhaps we should go even further and determine general precedence rules for mixing
RUSTFLAGS input with command line input. But I digress.
But if we want to continue having rustc be strict about that, then x.py needs to be smarter about looking at the environment when it decides what arguments to pass to the rustc it invokes.
Right, now, if I do
RUSTFLAGS=--color=never x.py build, I get:My initial inference here is that we are dying because
rustcis getting multiple--color=neverdirectives (and one is coming in implicitly viaRUSTFLAGSIn my opinion,
rustcshould allow one to pass--color=nevermultiple times. (Arguably other combinations of--colorshould also be allowed.)RUSTFLAGSinput with command line input. But I digress.But if we want to continue having
rustcbe strict about that, thenx.pyneeds to be smarter about looking at the environment when it decides what arguments to pass to therustcit invokes.