[cmake-developers] [CMake] Forcing colorization of output from cmake

[Brad King]

On 10/09/2014 01:38 PM, Paul Smith wrote:
> What I really want is that if MAKE_TERMOUT is set to a non-empty value,
> cmake should pretend that it's in a terminal regardless of what isatty()
> says.  We can do this easily enough by adding a simple test to
> Terminal.c:kwsysTerminalStreamIsVT100() _without_ adding any code
> anywhere else:

One problem with this is that non-make processes launched by make may
run their own children to capture the output through pipes and not
unset MAKE_TERMOUT.  We need it to be 'make' that evaluates that env
variable.  Your original command-line approach did this.

> In a way this is gross, certainly, but this function already checks for
> environment variable such as TERM, EMACS, etc. which are set by calling
> utilities and handles them specially.  So why not MAKE_TERMOUT as well?

The TERM and EMACS variables are checked to determine whether the
terminal supports color when isatty() returns true.  That is not
the same as forcing tty behavior.

> I would expect FORCE to be stronger than that, and return
> true regardless of TERM settings.

Okay, but the internal API in KWSys Terminal needs to be more granular
than that.  Please revise your patch to use my KWSys part but also
add a ForceVT100 setting that causes TERM and EMACS to be ignored.
Then the --switch=FORCE can set both the ForceTTY and ForceVT100
setting internally.

> I'm not at all familiar with Windows so I have no strong opinions on
> whether FORCE should also force color output on a Windows console...
> although I know a number of people who do use GNU make on Windows and
> the Windows port of GNU make does set MAKE_TERMOUT properly.

Native Windows terminals do not support the color escape sequences
at all.  We need to get a handle to the underlying console buffer and
set parameters on it directly.  If the output pipe is not connected
to a real console then we cannot get the console handle and print
color at all.

>> We already have a CMAKE_COLOR_MAKEFILE option.  Perhaps instead
>> of just ON or OFF values it could have a GNU value that enables
> 
> Well, it's easy enough to detect if CMAKE_MAKE_PROGRAM is GNU make, if
> we can run it to test the output of "${CMAKE_MAKE_PROGRAM} --version".
> 
> The question is, what do you do in the generated makefile if you see
> that it's GNU make?

The CMake generator would recognize CMAKE_COLOR_MAKEFILE==GNU and
enable the GNU-specific content.  CMAKE_COLOR_MAKEFILE is a cache
setting the user could set if they don't like the default.  We can
set the default based on whether the CMAKE_MAKE_PROGRAM is GNU.

> It would need to be the equivalent of:
> 
>    --switch=$(or $(COLOR),$(if $(MAKE_TERMOUT),FORCE))
> 
> to preserve the current behavior, where the COLOR variable setting can
> be inherited from the environment.

Yes.

> What if someone runs cmake and it detects GNU make, but then they run
> "/my/other/make" which is not GNU make?  That would work fine now but
> fail if we generated GNU-specific content in 'Unix Makefiles'
> generators.

The user could always set CMAKE_COLOR_MAKEFILE to ON instead of GNU
to work with other make tools.

> If we had a different generator, like 'GNU Makefiles' for example, then
> people who chose that would clearly expect the results would only work
> with GNU make, but we don't have that.

One day we may create a 'GNU Makefiles' generator to enable use of
GNU-specific features, but that would need to be a more comprehensive
effort than just changing the color option.

Thanks,
-Brad