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

[Paul Smith]

Thanks Brad.  I wrote a bunch more below and left it for posterity.
However thinking more about this I wonder if we couldn't make this
simpler.

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:

   /* Check for a valid terminal.  */
   if(!default_vt100)
     {
     ...
     }
+
+  /* If we're being run from GNU make 4.1+ see if IT thinks we have a TTY.  */
+  const char* termout = getenv("MAKE_TERMOUT");
+  if(termout && termout[0] != '\0')
+    {
+    return 1;
+    }

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?

That one change is enough for my particular use-case, without any other
changes (don't need a FORCE setting for color).  I think it would be
useful to allow FORCE (I think this is a good capability to provide; as
I mentioned other tools that support colorization such as GCC etc. to
provide an "always"-type flag) but it would be decoupled from this GNU
make capability.

Thoughts?


On Thu, 2014-10-09 at 09:55 -0400, Brad King wrote:
> The Source/kwsys part of the change actually belongs in a separate
> KWSys upstream first.  I've added a modified version of your change
> for upstream review and testing here:
> 
>  http://review.source.kitware.com/17578
> 
> Please try out that version with the rest of your changes.

OK.  I see that in your version FORCE only comes into effect if we have
a "known good" terminal (the new code comes after the check for valid
terminal).

Personally I would expect FORCE to be stronger than that, and return
true regardless of TERM settings.  Whether or not it should override
EMACS env.var. I don't know... I'm on the fence.  In my solution I had
it really FORCE; that is, kwsysTerminalStreamIsVT100() effectively
always was true if --switch=FORCE, regardless of EMACS or TERM.

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.

> > it's darn handy to have this "just work" without having to export
> > COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever.
> > There's no "GNU Makefiles" generator, and I couldn't come up with a good
> > way to implement this in the generic Unix Makefiles generator.
> 
> We already have a CMAKE_COLOR_MAKEFILE option.  Perhaps instead
> of just ON or OFF values it could have a GNU value that enables
> this behavior.  When initializing it in CMakeGenericSystem.cmake
> perhaps it is possible to detect if CMAKE_MAKE_PROGRAM is a GNU
> make tool and provide a good default.

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?  Anything you'd generate into the makefile that
could choose to set --switch=FORCE would have to be GNU-specific (I
can't think of a way to write it using POSIX standard makefile syntax).
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.

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.

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.