This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/36150] colorize output of gcc
- From: "esigra at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 May 2008 18:40:29 -0000
- Subject: [Bug other/36150] colorize output of gcc
- References: <bug-36150-14488@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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