[Bug other/36150] New: colorize output of gcc

[Bug other/36150] New: colorize output of gcc

[pva at gentoo dot org]

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.


-- 
           Summary: colorize output of gcc
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pva at gentoo dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-06 15:28 -------
I don't think we should do this.  There is already a secondary program that
does the coloring too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[esigra at gmail dot com]

------- Comment #2 from esigra at gmail dot com  2008-05-06 17:27 -------
I would definitely like GCC to produce colourized output. It can really improve
the readability. I miss that feature. It has my vote.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-06 17:35 -------
http://schlueters.de/colorgcc.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2008-05-06 17:37 -------
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 .


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[pva at gentoo dot org]

------- Comment #5 from pva at gentoo dot org  2008-05-06 18:07 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[esigra at gmail dot com]

------- Comment #6 from esigra at gmail dot com  2008-05-06 18:40 -------
(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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[brian at dessent dot net]

------- Comment #7 from brian at dessent dot net  2008-05-06 21:28 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[esigra at gmail dot com]

------- Comment #8 from esigra at gmail dot com  2008-05-06 21:55 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2008-05-06 21:58 -------
The other issue here is that people want different colors for each of their
warnings so why hardcode it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[brian at dessent dot net]

------- Comment #10 from brian at dessent dot net  2008-05-06 22:06 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150

[Bug other/36150] colorize output of gcc

[pva at gentoo dot org]

------- Comment #11 from pva at gentoo dot org  2008-05-07 06:54 -------
(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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150