Re: [rfc] Colorized output for GNU make?

[Paul Smith]

On Thu, 2012-01-05 at 22:42 +0100, Sebastian Pipping wrote:
> On 01/05/2012 09:46 PM, Eli Zaretskii wrote:
> > The easiest way of abstracting this is to have a function that turns
> > on a given color, and another function that turns off a color and
> > returns to the default color.  ("Color" can actually be some other
> > attribute, like bold or blinking.)  There should be a way to do this
> > separately for foreground and background colors.
> 
> Is this about the extraction of two functions of three lines each or is
> it about more?

It seems like we have two distinct things going on.  The first one is
creating a common infrastructure for formatting messages, so we can
generate a single string to be printed: that's the prefix stuff etc.

The second one is the colorized output itself: both the command line
settings, as well as ultimately turning on/off colors.

Today those two things are kind of stuck together, in a single file.  If
we wanted to, for example, support ncurses for output instead of direct
ASCII control chars, it's not easy without duplicating a lot of common
code for the formatting part.

Or consider the other requests we saw on this list, where instead of the
output being colorized it's printed in some kind of structured format
for easier parsing (depending on the structure it would be hard to do
this 100% because today we don't control the output of recipes... but if
we integrated the "parallel program output synchronization" feature we
could even potentially do this as well).


Maybe a way forward would be to take the code that formats the messages
into a string and move that code into misc.c or similar.  That's generic
and not related to colorizing.  Then have a function that took a message
string (constructed by the formatting function probably?), and some
details about the kind of attributes to use, and put that function in a
file like "output_ascii.c" or something with a well-defined interface,
so other files like "output_ncurses.c" or whatever could be written to
that same interface and dropped in.

There might have to be some kind of handshake between the generic code
and the colorized code for verifying command line arguments that set
attributes, so the colorizing code can reject things it doesn't
understand for example.

Does that make sense?