Bug 36150 - colorize output of gcc
Summary: colorize output of gcc
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 45850 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-05-06 09:35 UTC by Peter
Modified: 2014-01-20 02:41 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter 2008-05-06 09:35:46 UTC
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.
Comment 1 Andrew Pinski 2008-05-06 15:28:02 UTC
I don't think we should do this.  There is already a secondary program that does the coloring too.
Comment 2 esigra 2008-05-06 17:27:38 UTC
I would definitely like GCC to produce colourized output. It can really improve the readability. I miss that feature. It has my vote.
Comment 3 Andrew Pinski 2008-05-06 17:35:12 UTC
http://schlueters.de/colorgcc.html
Comment 4 Andrew Pinski 2008-05-06 17:37:44 UTC
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 .
Comment 5 Peter 2008-05-06 18:07:47 UTC
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.
Comment 6 esigra 2008-05-06 18:40:28 UTC
(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?
Comment 7 Brian Dessent 2008-05-06 21:28:56 UTC
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.
Comment 8 esigra 2008-05-06 21:55:54 UTC
(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.
Comment 9 Andrew Pinski 2008-05-06 21:58:02 UTC
The other issue here is that people want different colors for each of their warnings so why hardcode it.
Comment 10 Brian Dessent 2008-05-06 22:06:56 UTC
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.
Comment 11 Peter 2008-05-07 06:54:31 UTC
(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...

Comment 12 Andrew Pinski 2010-10-02 17:03:33 UTC
*** Bug 45850 has been marked as a duplicate of this bug. ***
Comment 13 Manuel López-Ibáñez 2010-10-02 17:52:39 UTC
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.

[*] http://fseek.me/2010/03/how-to-convince-any-c-developer-to-dump-gcc-and-use-clang/
Comment 14 Manuel López-Ibáñez 2010-10-02 19:51:34 UTC
For future reference, more examples of color diagnostics in clang can be found here:

http://llvm.org/devmtg/2009-10/StateOfClang.pdf

but that is quite old, recent clang versions may produce a different output.
Comment 15 Manuel López-Ibáñez 2011-03-16 14:41:50 UTC
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/
Comment 16 Manuel López-Ibáñez 2013-04-14 17:57:47 UTC
GCC 4.9 will have colorized diagnostics, although probably disabled by default: 

http://gcc.gnu.org/gcc-4.9/changes.html
Comment 17 bluetooth.developer 2014-01-20 02:41:04 UTC
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:
http://www.onlysolutionssoftware.com/gilcc/