colormake should replace default make

[Manuel López-Ibáñez]

colormake should replace default make, so when I call make the output is colorised (which was the intended result when I installed this package).

Currently, it is neccesary to call colormake directly.

This bug is similar to bug 30734 in colorgcc and the solution to both should be equivalent.

[Barry deFreese (bddebian)]

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.

[Manuel López-Ibáñez (manuellopezibanez)]

What needs to be discussed? If you install colorgcc is because you want coloured gcc. The same for colormake. I don't know who is going to want to discuss this.

On the other hand, I don't have the time right now to provide a patch for this, I was hoping that being an open wish, someone may decide to fix it.

[Guillaume Desmottes (cassidy)]

I definitely agree with you Manu. colormake should be automatically used after its installation (same for colorgcc and colordiff).

I'm wondering what's the good way to do that. Using alternatives or something?

[Manuel López-Ibáñez (manuellopezibanez)]

Perhaps it should use the same system used for awk/gawk/mawk.

[Guillaume Desmottes (cassidy)]

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

[Ludovic Rousseau (ludovic-rousseau-gmail)]

The goal of colormake is to add side effects to the make command (add colors to the output).
Some scripts use make and may be very broken if the output of make contains colors added to the normal output.

Replacing make by colormake will have desastrous (and hard to debug) side effects.

If you want you can just configure your bash to use colormake by default:
$ alias make=colormake

I (Debian maintainer of colormake) propose to close/reject this bug.

[Manuel López-Ibáñez (manuellopezibanez)]

By "replacing", I meant "taking the steps necessary so the output of make shown to the user is colorised". That is exactly what your suggestion does. It seems to me a pointless step to force users to figure out how to do this additional step (properly!), when there is a package management system that is able to install everything that is needed to make it work out-of-the-box. On the other hand, in this particular case, I guess that if you know what 'make' is you should know what 'alias' is.

In any case, my .bashrc contains, which works with or without colormake installed.

# enable color support of ls and also add handy aliases
if [ "$TERM" != "dumb" ] && [ -x /usr/bin/dircolors ]; then
    eval "`dircolors -b`"
    alias ls='ls --color=auto'
    alias dir='ls --color=auto --format=vertical'
    alias vdir='ls --color=auto --format=long'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
    if [ -x /usr/bin/colormake ]; then
        alias make='colormake'
    fi
    if [ -x /usr/bin/colordiff ]; then
        alias diff='colordiff'
    fi

fi

So, this bug does not affect me anymore, and I personally do not care much if you close/reject it (and bug 30734).

[Ludovic Rousseau (ludovic-rousseau-gmail)]

It may be a very bad idea to make colormake replace make by default.

colormake generates color codes even if the output is not a terminal. If you do:
$ colormake > foo
then foo will contain the color change codes.

It would break a lot of scripts that try to parse the output of make and would be perturbed by the color codes added by colormake.