colorgcc should replace default gcc

Thanks for your suggestion. The changes you are requesting require more discussion, which should be done on an appropriate mailing list or forum. <http://www.ubuntu.com/community/forums/> might be a good start.

I reopen this bug as I don't see the point to discuss about a RFE on forums instead of on our bug tracker.

I agree with this RFE, I installed colorgcc in the hopes it would colourize my gcc output.

Just installing it doesn't appear to be enough

So far I'm trying:
alias gcc='colorgcc'
export CC="gcc"

I'm not sure if this is the "right" way to go though...

The right way is for colorgcc to use the alternatives system in the same way that other packages do (for example gs, gs-eps, gs-gpl, etc, or the very same gcc-4.1, gcc-3.4, etc).

This way, colorgcc gets installed as an alternative of gcc with higher priority. Then, colorgcc itself needs to be configured to find the actual gcc (which will probably be the second highest priority alternative to gcc).

I also agree with the proposed change here.

this is wishlist, confirmed

related thread:
http://ubuntuforums.org/archive/index.php/t-434787.html

I find the instructions at http://blog.emptycrate.com/node/429 work fine. Specifically issuing the following commands manually once after installation. The fact these sym-links aren't automatically created during installation seems, to me, a defect in the installation package which could easily be fixed.

sudo ln -s /usr/bin/colorgcc /usr/local/bin/gcc
sudo ln -s /usr/bin/colorgcc /usr/local/bin/g++
sudo ln -s /usr/bin/colorgcc /usr/local/bin/cc
sudo ln -s /usr/bin/colorgcc /usr/local/bin/c++

or when run with root privileges during installation, the following single line would accomplish the same thing.

ln -s /usr/bin/colorgcc /usr/local/bin/gcc; ln -s /usr/bin/colorgcc /usr/local/bin/g++; ln -s /usr/bin/colorgcc /usr/local/bin/cc; ln -s /usr/bin/colorgcc /usr/local/bin/c++

Debian/Ubuntu have a system to handle alternatives for programs. In any case, parsing the output of gcc is prone to errors. It would be better if gcc implemented colors

To clarify, colorgcc is just a wrapper for the real gcc, etc. The above symlinks in /usr/local/bin/* are found before the real gcc, etc. in /usr/bin/* (owing to the default path variable - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games). The title and description of this bug should be ammended.

If my previous suggestion can be integrated in to the repository package, the sym-links should automatically get removed during uninstallation so that when the path is traversed to execute gcc, etc. the original ones are then found.

Ah ok, sorry. I didn't refresh the page before my last message and missed what you said about the debian/ubuntu alternatives system. It would be nice if the gcc system implemented colors and I don't know much about the alternatives system. I'll read about the alternatives system and see if the colour functionality can just be patched directly in to gcc. Thanks for your quick reply.

As most of what is seen in the terminal is colored (ls, vim, etc.) by default gcc's output may also be in color.

#11

The current maintainers of GCC have already said that they do not want to implement color output in GCC.

http://gcc.gnu.org/PR45850

http://gcc.gnu.org/PR36150

I have a preliminary patch, so if Ubuntu would be willing to carry the patch, I would finish it. However, most distributions are very conservative about patching GCC.

Addition to #12: I'm referring to gcc as it gets shipped by Ubuntu.

I agree. Please make colorgcc the default. Most of the development tools like git, Python or whatever have colourised output nowadays. It's ludicrous that gcc is stuck in the past - especially with such huge output that often spans 2 pages worth of template errors.

GCC 4.9 supports colors out of the box, thus the current colorgcc is not needed anymore.

Ubuntu should just enable GCC colors by default. See https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1324901 for a possible way to do this.