Bug 1315785 - Invoke cargo with --color=always when original stdout is a TTY; r=glandium
authorGregory Szorc <gps@mozilla.com>
Mon, 07 Nov 2016 13:46:15 -0800
changeset 348355 6cf52ce48a48cd67d074ce985f6675acc9cbe04b
parent 348354 6e9a4c0b9cd82f37275025e009e4fd327bdcd819
child 348356 e886c6e03475254a8eb4d40da99502744dda28f1
push id10298
push userraliiev@mozilla.com
push dateMon, 14 Nov 2016 12:33:03 +0000
treeherdermozilla-aurora@7e29173b1641 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
Bug 1315785 - Invoke cargo with --color=always when original stdout is a TTY; r=glandium Combined with the previous patch that sets MACH_STDOUT_ISATTY, the practical effect of this patch is that cargo is invoked with `--color=always` when mach was attached to a TTY and colorized output is sent to the terminal. Note: this doesn't work with Rust/Cargo 1.10 for reasons unknown to me. It appears there was a bug with Rust/Cargo because `--color=never` still sent colorized output on that version! Cargo/Rust 1.12.1 works fine. MozReview-Commit-ID: 6uXS3t3413i
--- a/config/rules.mk
+++ b/config/rules.mk
@@ -916,16 +916,25 @@ endif
 cargo_build_flags += --frozen
 cargo_build_flags += --manifest-path $(CARGO_FILE)
 cargo_build_flags += --target=$(RUST_TARGET)
 cargo_build_flags += --verbose
+# Enable color output if original stdout was a TTY and color settings
+# aren't already present. This essentially restores the default behavior
+# of cargo when running via `mach`.
+ifeq (,$(findstring --color,$(cargo_build_flags)))
+cargo_build_flags += --color=always
 # Assume any system libraries rustc links against are already in the target's LIBS.
 # We need to run cargo unconditionally, because cargo is the only thing that
 # has full visibility into how changes in Rust sources might affect the final
 # build.
 	env CARGO_TARGET_DIR=. RUSTC=$(RUSTC) $(CARGO) build $(cargo_build_flags) --