Skip to content

x.py should not die if I set RUSTFLAGS=--color=never in the env #49838

Closed as not planned
@pnkfelix

Description

@pnkfelix

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-enhancementCategory: An issue proposing an enhancement or a PR with one.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions