On Fri, Jun 22, 2018 at 02:08:27PM -0600, Jeff Law wrote: > On 06/12/2018 04:46 PM, Adam Borowski wrote: > > Here's a patch for Bugzilla 80271, to add support for env CLICOLOR_FORCE. > > > > Automated build environments -- and even some which you run by hand -- > > redirect the output somewhere to save a log, even if they tee it to the > > terminal anyway. This kills all colored highlights for diagnostics. > > Those highlights are really nice for a human -- unlike the old days when > > a single-threaded build always had the failure at the end, modern setups > > tend to spew pages of stuff after the real reason your build failed. As > > human vision evolved to be extremely good at noticing a fleck of color, > > it's easy to spot that bit of red even when scrolling very fast. > > > > Besides terminals, you can read colored logs via "less -R", ansi2html, etc. > > > > For such piped setups, gcc has -fdiagnostics-color=always. Alas, while this > > flag is easy to set by someone writing a given piece of software, there's > > no reasonable way to set it globally in the build environment. > > > > Thus, in #80271 Jan Niklas Hasse requested, and I concur, to be able to > > set the same via an env var. This flag doesn't affect code produced by gcc > > in any way, thus it's reasonable to set it via env. There's already > > GCC_COLORS letting you customize colors used, you just can't tell it to > > ignore stderr not being a terminal.
> We _strongly_ discourage the use of environment variables to control the > compiler. Really the way to go here is to use the > -fdiagnostics-color=always and deal with the difficulties of flag injection. As discussed in #80271, color vs b&w diagnostics don't change any produced files in any way. The presentation of these diagnostics is already affected by things not included in -f args (namely, isatty(2)). And, this very feature is already controlled by another env variable, ie, GCC_COLORS. Another reason is that, certain build systems store -f flags and consider a build to be different if the flags differ. This can cause spurious recompiles just because one invocation was redirected but another was not, something likely to happen in a debugging session. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄⠀⠀⠀⠀ go back and forth wrt their intended target.
