[Bug 700833] Review Request: colorgcc - Script to colorize the terminal output of gcc, g++, cc, c++

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=700833

--- Comment #5 from Martin Cermak <mcermak at redhat.com> 2011-05-06 02:56:56 EDT ---
> Needs work:
> -----------
> - Please use the full URL for Source0
>
> - The license tag should be GPL+, per:
>   http://fedoraproject.org/wiki/Licensing
>   See the GPL (no version) table
>
> - If you're not adding a %clean, nor cleaning the buildroot in %install, you
> should not specify a buildroot at all, so drop:
> BuildRoot:  %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
>
> - A bitter way to handle %prep would be:
> %prep
> %setup -q -c -T
> cp -p %{SOURCE0} .
> %patch0 -p1
>   You can then also drop the "cd %{name}-%{version}" from %install

This should be resolved in colorgcc-1.3.2-2:

Spec URL: http://www.physics.muni.cz/~cermak/colorgcc-1.3.2-2/colorgcc.spec
SRPM URL:
http://www.physics.muni.cz/~cermak/colorgcc-1.3.2-2/colorgcc-1.3.2-2.fc14.src.rpm
Patch0 URL:
http://www.physics.muni.cz/~cermak/colorgcc-1.3.2-2/colorgcc-1.3.2-invocation.patch

$ rpmlint colorgcc.spec
colorgcc.spec: W: no-%build-section
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

$ rpmlint colorgcc-1.3.2-2.fc14.src.rpm
colorgcc.src: W: no-%build-section
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

$ rpmlint colorgcc-1.3.2-2.fc14.noarch.rpm
colorgcc.noarch: W: no-documentation
colorgcc.noarch: W: no-manual-page-for-binary color-gcc
colorgcc.noarch: W: no-manual-page-for-binary color-g++
colorgcc.noarch: W: no-manual-page-for-binary color-cc
colorgcc.noarch: W: no-manual-page-for-binary color-ccache
colorgcc.noarch: W: no-manual-page-for-binary color-c++
1 packages and 0 specfiles checked; 0 errors, 6 warnings.


> Hmm, is there an easy way to call ccache instead of gcc within colorgcc?
> Currently I have this for calling colorgcc:
> $ ll /usr/local/bin/
> insgesamt 0
> lrwxrwxrwx. 1 root root 15 15. Mai 2010  cc -> /usr/bin/ccache
> lrwxrwxrwx. 1 root root 15 15. Mai 2010  g++ -> /usr/bin/ccache
> lrwxrwxrwx. 1 root root 15 15. Mai 2010  gcc -> /usr/bin/ccache
>
> Replacing that link to color-gcc will unfortunately disable ccache...

On a fresh F14 system, ccache is called transparently if you call gcc:

$ strace -eexecve -f gcc hello.c 2>&1 | grep ^execve | grep -v ENOENT
execve("/usr/lib64/ccache/gcc", ["gcc", "hello.c"], [/* 33 vars */]) = 0
execve("/usr/bin/gcc", ["/usr/bin/gcc", "hello.c"], [/* 34 vars */]) = 0

So I just removed absolute paths pointing to compiler binaries from colorgcc.
Now it should work as expected if you have ccache installed:

$ strace -eexecve -f color-gcc hello.c 2>&1 | grep ^execve | grep -v ENOENT
execve("/usr/bin/color-gcc", ["color-gcc", "hello.c"], [/* 33 vars */]) = 0
execve("/usr/lib64/ccache/gcc", ["gcc", "hello.c"], [/* 33 vars */]) = 0
execve("/usr/bin/gcc", ["/usr/bin/gcc", "hello.c"], [/* 34 vars */]) = 0

And also if you haven't:

trace -eexecve -f color-gcc hello.c 2>&1 | grep ^execve | grep -v ENOENT
execve("/usr/bin/color-gcc", ["color-gcc", "hello.c"], [/* 33 vars */]) = 0
execve("/usr/bin/gcc", ["gcc", "hello.c"], [/* 33 vars */]) = 0

And I also provided the color-ccache link:

$ rpm -ql colorgcc
/usr/bin/color-c++
/usr/bin/color-cc
/usr/bin/color-ccache
/usr/bin/color-g++
/usr/bin/color-gcc

Hope I didn't miss something. What remains is to set up some nice aliases... :)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.