It could be useful if gcc colorizes its output. Colors allow easier to distinguish errors and warnings from makefile commands and etc... Currently there exist a separate script like colorgcc which colorizes output of compiler but it does not works with localized bugs.gentoo.org/168709 output so seems that it's better to have colorizing functionality in gcc itself as only gcc knows better what output it issues.
I don't think we should do this. There is already a secondary program that does the coloring too.
I would definitely like GCC to produce colourized output. It can really improve the readability. I miss that feature. It has my vote.
I rather not add too much complexity to gcc diagnostic output. Which means no color. colorgcc could be extended to get the correct coloring for the locazation.
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983 .
Andrew, it's very pity to see this bug closed as invalid so fast. Besides being useful, people enjoy colors and people work with compilers...
I've already stated that, but I repeat. colorgcc does not work in case you have localized output (see our bug report). Reading source of colorgcc it seems that it uses words like "warning" or error as a key to parse and colorize output. Thus taking into account the number of human languages gcc is translated to and will be in future, adding complexity of having different encodings leaves colorgcc hardly working without "fixing it with rasp-file" after translation updates or additions. The complexity of this makes me think that it's natural to have this feature in place where error/warning is thrown - that is in gcc itself...
bug 36150 although could help, as it makes possible to parse error based on numbers, works only for languages with stable "references" where it's hardly possible that numbers changes, as in other case wrong coloring could mislead programmer...
Summarizing, I do not see why decision error or warning we have should be decided based on output after gcc and not in first place - in gcc itself - where it's known with high certainty.
(In reply to comment #4)
> I rather not add too much complexity to gcc diagnostic output. Which means no color.
We did not demand that you do it personally. We just think that it would be a really good idea if someone would do it some time. Just how much complexity would it take?
> colorgcc could be extended to get the correct coloring for the locazation.
Sure it *could* be done, but it would require a version of colorgcc for each (combination of GCC version and) localization. Now we are talking about complexity!
Localized output is inherently unsuitable for parsing. The existence of such an ugly hack is certainly no excuse for not allowing a proper implementation in GCC itself, where it belongs. And seriously, what is more efficcent, adding a colour code sequence to the string constans in GCC that says "warning:", "error:" etc or having a bunch of scripts for parsing the output of various GCC versions/localizations, recreating it with colour codes? What would distributions prefer to maintain?
Subject: Re: colorize output of gcc
esigra at gmail dot com wrote:
> And seriously, what is more efficcent, adding a
> colour code sequence to the string constans in GCC that says "warning:",
> "error:" etc or having a bunch of scripts for parsing the output of various GCC
If you added escape sequences to the string constants in the gcc source
then it would only work for the C locale messages. And isn't your whole
complaint that colorgcc fails for non-C locales? In other words, this
would not do anything in the very case you care about, because in non-C
locales the message strings are taken from the po file and not the
literal strings in the source code.
(In reply to comment #7)
> If you added escape sequences to the string constants in the gcc source
> then it would only work for the C locale messages.
Adding escape sequences for colours would work as well with localization as any other formatting. Simple example:
printf("%s%s%s%s", warning_format_start, _("warning: "), _("the actual message"), warning_format_end);
Here warning_format_start may be a pointer to "<orange>" and warning_format_end a pointer to "</orange>". If colours are disabled, they both point to "". So the result might be "warning: the actual message" or "<orange>warning: the actual message</orange>". Localization would work fine for both "warning: " and "the actual message". I do not really see the problem that you were thinking of.
The other issue here is that people want different colors for each of their warnings so why hardcode it.
Subject: Re: colorize output of gcc
esigra at gmail dot com wrote:
> printf("%s%s%s%s", warning_format_start, _("warning: "), _("the actual
> message"), warning_format_end);
But then that is not simply "adding a colour code sequence to the string
constans in GCC", i.e. you can't just grep for "warning:" and change it
to "\033[01;32warning:", it's much more involved.
(In reply to comment #9)
> The other issue here is that people want different colors for each of their
> warnings so why hardcode it.
It should be easy to make this configurable...
Well I've googled a bit and did not found any simple library to abstract from color codes. Thus I've looked at cmake sources which colorizes it's output and found that they do everything by themselves. By default (if not disabled through command line and if test for cases where colors are not support fail) they enable colors supposing that they have vt100 terminal and colorize output. Take a look at kwsys/Terminal.c - the code itself is small and clear... This does not seem to be a hard task to implement something similar in gcc.
(In reply to comment #10)
> you can't just grep for "warning:" and change it to "\033[01;32warning:", it's
> much more involved.
Oh, no. Not taking into account that you'll have to rebuild gcc every time you decide to change colors, things like output or not colors should be decided at runtime (looking at $TERM) as on terminals which do not support colors output became unreadable...
*** Bug 45850 has been marked as a duplicate of this bug. ***
Somehow I missed this bug when searching. For those here in favour of color, clang has it and people love it [*]. Luckily, this is one of those clang things that can be done in GCC, and it works with localized messages. I have a prototype patch and it is not too big. Unluckily, it seems it would be rejected anyway, so I won't bother to clean it up and do all the bureaucracy stuff. Shame.
For future reference, more examples of color diagnostics in clang can be found here:
but that is quite old, recent clang versions may produce a different output.
More users trying to get this feature by parsing the output of GCC (which is not meant to be machine-readable): http://www.mixtion.org/gccfilter/
GCC 4.9 will have colorized diagnostics, although probably disabled by default:
Alternatively you could use GilCC which is a tool to colorize GCC output in real time. Just in case you cannot use GGC version 4.9 you still can use GilCC.
here is the download link: