Re: [rfc] Colorized output for GNU make?

[Paul Smith]

On Sun, 2012-01-01 at 01:31 +0100, Sebastian Pipping wrote:
> > I have to say that I feel that David's
> > point of 20 Oct is well-taken, that a more flexible command line
> > interface would be better.
> 
> Alright.  I propose to transform
> 
>   --output-format=(color|plain)
> 
> into
> 
>   --format=(plain|colorized) .
> 
> What do you want the parameter to look like?

I'm not sure what you mean by "the parameter"?  The above looks OK to me
although I prefer "color" (and allowing "colour" for our non-U.S.
English speakers).

As for the code, I have a concern about the way strings are being
constructed.  One of the hardest parts about generating output in a GNU
program is the requirement to support i18n.  GNU make is not perfect but
it is making strides and I think the new behavior actually moves us a
step backwards.  I'm thinking in particular of the PREFIX capabilities.

The problem is that not all languages are read left-to-right: some are
read right-to-left.  So, if you create output strings with prefixes that
are generated first and not part of the translated string, then those
prefixes cannot be "swapped" for languages that are read right-to-left:
they always come on the left, when they should come on the right.

Some of the output we generate, such as the error() function, already
has this problem.  But in other areas we avoid it by constructing the
string completely including the prefix, and translating that.

I confess I'm not an expert in i18n, so it's quite possible I'm making
something out of nothing very important here.  But I think it's worth
investigating.  It's possible, for example, that it's sufficient to
"translate" the prefix string itself if everything is printed in one
invocation.


Beyond that, I'm not excited about having to add a parameter specifying
whether there's a newline or not.  I'm assuming that if you don't switch
back the color to the default before the \n is printed, you get ugly
output, is that it?  I'd actually prefer the output.c code to be a
little more complex and check to see if the string ends in a newline and
handle that internally, rather than have all the callers have to pass a
special flag specifying newlines.

Ditto for the flush() call.  I'm not sure why we'd ever want to NOT
flush, and I'm not sure why there's an explicit flush() some places but
not others.

If we do end up needing extra flags, I wonder if there's some way to
combine them with the message type to avoid needing an extra parameter.


Also please don't worry about updating copyright years: I have a utility
that does that automatically for all the files at once.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist