[PATCH] D152285: Add support for the NO_COLOR environment variable

[Alexander Richardson via Phabricator via cfe-commits]

arichardson added a comment.



>>> [...] I don't know what compelling use case there is for forcing colors *on*, [...] until we know why users need to force-enable colors.
>>
>> The reason is that adding `-fcolor-diagnostics` to the command line is not always feasible, e.g. most build systems would rebuild everything in that case. Relying on tty detection also doesn't work as many build tools buffer the output (and some CIs, too).
>
> Ah, that's an interesting use case, thank you for mentioning it! I'm not certain that's super compelling to me; color diagnostics are on by default, so if someone forcibly disables them in the build system (which seems to not really happen too much in practice: https://sourcegraph.com/search?q=context:global+-fno-color-diagnostics+file:.*Makefile.*&patternType=standard&sm=0&groupBy=repo), that's likely done for a reason.

I had the same use case quite a few years ago: I wanted to have Jenkins output coloured diagnostics in the logs to make them slightly easier to read. since the output goes to a file rather than a terminal it defaults to no colours and there were too many different build systems involved that adding compiler flags was not feasible. In the end I added a local hack to clang to default to colours being on if a given environment var is set (https://github.com/CTSRD-CHERI/llvm-project/commit/a427ffe13c19276ae94cc757632439fda08d9dc6). I'd be happy if we ended up supporting CLICOLOR_FORCE=1 as a way of ignoring the isatty check but colours in Jenkins without modifying build systems is just a nice to have feature rather than something super useful and there are better ways of making the warnings more visible (e.g. the plugin that scans the build logs and aggregates results).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152285/new/

https://reviews.llvm.org/D152285