[CMake] Forcing colorization of output from cmake

[Paul Smith]

On Wed, 2013-05-01 at 10:18 -0400, Paul Smith wrote:
> I'm wondering if there's any way to force the output from cmake (using a
> unix makefile generator for example) to be colorized, even if stdout
> doesn't appear to be a TTY.
> 
> Is that possible?  Some extra switch to cmake_echo_color?

I sent this a year and a half ago or so, but no response.  Reading the
code it doesn't appear to be possible.  I tried forcing the --switch=ON
flag in the cmake_echo_color command, but that doesn't help.

This is an important issue because newer versions of GNU make provide a
way to avoid having output from multiple jobs jumbled together during
parallel builds, which is extremely helpful; however obviously this
requires that the output be redirected to a temporary file rather than
displayed directly on the terminal.  Making use of this feature means
that you lose colorized output from cmake makefiles.

However, GNU make (4.1) provides an environment variable which tells its
children whether IT was started with a terminal for stdout/stderr:
MAKE_TERMOUT will be non-empty if make believes that its output will
eventually be dumped to stdout: ditto for MAKE_TERMERR.

So I thought about adding this into my environment:

  export COLOR='$(if $(MAKE_TERMOUT),YES)'

and that does work to set "--switch=YES" when make thinks that it's
output is stdout, but that doesn't help because cmake ignores this
setting.  I traced the code through and found that at the end we simply
run isatty() on the output stream, and if that returns false we never
colorize and there's no option to manage this.

Compare this to other tools such as GCC, where they allow you to force
colorization always, regardless of the TTY settings.

Maybe we could add another valid value to --switch, like --switch=FORCE
which would always colorize.

There are a number of layers between where cmake parses the command line
and where it makes the decision on whether to colorize or not.  The best
option seems to be to add another flag to the "color" bitflag variable
that forces colorization always.  The AssumeTTY flag kind of does this,
but currently it's only enabled on Windows and doesn't quite fit the
bill: its use and meaning would need to be tweaked I think.