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

[Paul Smith]

On Wed, 2014-10-08 at 12:55 -0400, Brad King wrote:
> On 10/08/2014 12:15 PM, Paul Smith wrote:
> > Maybe we could add another valid value to --switch, like --switch=FORCE
> > which would always colorize.
> [snip]
> > The best option seems to be to add another flag to the "color" bitflag
> > variable that forces colorization always.
> 
> Yes, I think both of the above make sense.  If you want to work on
> it please read CONTRIBUTING.rst from the top of our source tree
> in Git ( http://cmake.org/cmake.git ) and come to the developers
> list with a proposal:

Hi all.  Attached please find a proposed patch for the above.  I still
think there's some slightly awkward redundancy between AssumeTTY and the
new ForceTTY, but I'm not sure these can actually be combined into one
flag... certainly not without reworking more of how AssumeTTY is
interpreted and used than I felt confident with.

I didn't try to allow "FORCE" to be case-insensitive.  It wouldn't be
hard, but I wasn't sure if it was worth it.  You must capitalize it as
the code is written today.  I found precedent for both options.

Also, the check for MAKE_TERMOUT might not be something you want to
keep... there's not a lot of precedent in the code, that I found, for
looking at other utilities' environment variables.  On the other hand
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cmake-Allow-forced-color-output.patch
Type: text/x-patch
Size: 7424 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20141008/d353ef86/attachment-0002.bin>