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
ifdef MOZ_CARGO_SUPPORTS_FROZEN
cargo_build_flags += --frozen
endif
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`.
+ifdef MACH_STDOUT_ISATTY
+ifeq (,$(findstring --color,$(cargo_build_flags)))
+cargo_build_flags += --color=always
+endif
+endif
+
# 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.
force-cargo-build:
$(REPORT_BUILD)
env CARGO_TARGET_DIR=. RUSTC=$(RUSTC) $(CARGO) build $(cargo_build_flags) --
