With the work going into updating distcc and ccache, I decided to also update colorgcc. This new ebuild improves things in several ways: Changed where colorgcc's wrapper symlinks are installed to be /usr/lib/colorgcc/bin (to be consistent with the new distcc and ccache) installs and extended the set of symlinks to include the missing CHOST versions of gcc. Superseded the *gcc_config.patch with a *wrapper.patch that implements the PATH-prefix-stripping idiom that I designed for distcc's ebuild. This makes the script automatically work wherever it is put into the PATH without the user needing to tell it what to execute next (though colorgcc supports a means of overriding this). This ebuild will make it easy to add colorgcc support to ebuild.sh (I'll comment about that on bug 2679, which is requesting that feature). Reproducible: Always Steps to Reproduce:
Created attachment 8097 [details] The improved colorgcc ebuild. If you just want to try this out, un-tar this into /usr/local/portage/dev-util (if you have the local portage support configured in make.conf) and "emerge colorgcc".
Created attachment 8157 [details] Updated colorgcc ebuild. Tweaked the sample colorgccrc file to comment-out the setting of the compiler values (since the script works out who to call on its own now).
I was looking at the colorgcc build in more detail, and I discovered that the debian patches are broken. The original 1.3.2 release uses the non-shell version of exec (so no shell meta characters need to be escaped), but the debian patches change this to use the a single string with explicit call to a shell (which results in two shells being spawned), but more importantly, not enough meta-char handling is being done to ensure that the args are processed correctly. For instance, this weird command: colorgcc "'foo>bar'" results in a shell syntax error and the file 'bar"' being created in the current directory. The fix is to go back to the original, non-shell using exec syntax of release 1.3.2. In my fixed version, the output is as it should be: gcc: 'foo>bar': No such file or directory I even went back to the original debian bug report and tried to duplicate what was in the bug. My only guess as to why the debian bug-reporter was seeing a failure was that open3() was not doing a proper exec @array call in 1999. This does not appear to be the case in a modern perl. Also of note, the tar file from the debian web site has several files that have DOS line-endings. They even include a patch that does nothing but replace all the lines in the colorgccrc file with identical lines that end in just a newline. I went back to the real home site for colorgcc, and the 1.3.2 tar file from there does not have this problem, so it is a better source file to start from.
Created attachment 8212 [details] My latest colorgcc ebuild. Here's a new ebuild that fixes the above exec bug, and includes all my previous enhancments plus one extra: I noticed that an ebuild that tries to use colorgcc fails to get color because the output is not going to a tty. I decided to add an environment variable that will allow the tty check to be turned off. I think that having this signaled in the environment is the right way to go because we only sometimes want this checking to be disabled, and we thus need a better way to temporarily tweak the setting than putting it into the colorgcc config file.
What about skipping color check if [ -n "$EBUILD" ] ?
I've actually decided that the tty-check-skipping part of my patch is a bad idea. It interferes with the ability for configure to interpret the output of the compiler, so it messes things up. I think a better solution is going to be to have colorgcc tweak the output of the ebuild command. I'm currently trying out a change that takes this route and will update my colorgcc ebuild when I get it done.
Created attachment 8619 [details] New colorgcc ebuild. This ebuild omits the part of my last patch that allowed the user to skip the tty checking (since that was a bad idea). What is new is adding a wrapper symlink for ebuild.sh (that is hard-configured to forward the command on to /usr/sbin/ebuild.sh). This will allow a change to the portage.py library to have it optionally call the ebuild.sh wrapper, and thus get its gcc output colored. (I'll comment on bug 2679 when I have that finished.) I also tweaked the regex in colorgcc slightly so that it wouldn't match non- error/warning lines that ebuild.sh can output. (This change should not affect the normal coloring of gcc/g++/etc.) To sum up, this ebuild improves upon the current colorgcc ebuild in the following ways: 1. It figures out for itself what program to call next (allowing the wrappers to be put into the PATH prior to distcc, ccache, or whatever else without having to tweak the config file). 2. It fixes the exec code to avoid any problems with shell meta characters (by avoiding the broken patch in the Debian version). 3. It uses a better starting tar so that files don't have DOS line endings. 4. It puts the wrapper symlinks into /usr/lib/colorgcc/bin (which make it consistent with the new distcc and my proposed change to ccache).
Created attachment 10049 [details] Latest colorgcc ebuild. This version of the ebuild has been updated to depend on the right perl category (which is dev-lang/perl these days) and to make two more minor tweaks to the coloration patterns.
Is there any reason why this shouldn't be checked in? I, too, use colorgcc and I'd welcome its integration into portage. Since #2679 depends on this ebuild, I'd like to see this go in.
One thing I thought of recently that the ebuild doesn't yet do: We should output a warning that tells users that they should modify any existing .colorgccrc files to remove hard-coded compiler paths (since the script now figures out who to call on its own). We should probably also mention to the user that the "masquerade dir" (where the symlinks are placed) has changed.
Created attachment 10354 [details] Another new colorgcc ebuild. Here's my latest version of this ebuild. Since Nicholas doesn't like the idea of having an ebuild.sh symlink in the colorgcc masquerade dir, I've removed that from the ebuild. I also added in some einfo output that tells users about the changes that happened that they should be aware of. Other changes: - We now install an /etc/colorgcc/colorgccrc file for global configuration and the support for this file has been restored to the ebuild (I had removed it for a while, but I think we should leave it as it was). - The INSTALL file now mentions the above colorgccrc file and no longer suggests configuring absolute compiler paths (which the user should not do anymore).
No reason but that I fixed it before, as nobody else wanted to. Talk to zwelch, if it fits with ccache/distcc, commit it if tests ok (not like the way you tested debianutils though :P).
Created attachment 10529 [details] More colorgcc improvements I've added a few more improvements to the colorgcc script: - Revised the rc-file parsing so that it doesn't have any hard-wired compiler names in the code (Debian has patches that extend the name matching, but this slight restructure is better, and won't ever need to be changed again to support different compiler names). - Added a filter mode when called as "colorgcc" (rather than as one of our masquerade symlinks). This allows someone to pipe output through colorgcc rather than having colorgcc exec a program (if desired). For instance, this might be used in ebuild.sh to color the data going into a portage log file (if Nick likes the idea). - Upgraded the script to "use strict" compliance. - Made my new code's style more closely match the style of the existing script (the "When in Rome..." rule of programming).
------- Additional Comments From kumba@gentoo.org 2003-18-09 12:35 EST ------- Gave this ebuild a test run on my x86 box. Seems basic gcc output is still white via portage, but haven't seen any warnings yet in the few packages I compiled. Must still need the changes in Bug #20356. However, with the ebuild working, anyone got any qualms if I commit this as -r4 of colorgcc (the ebuild is labelled -r9)?
------- Additional Comments From gentoo@blorf.net 2003-18-09 13:38 EST ------- Joshua: To see colored ebuild output after installing this ebuild you still need to apply the ebuild.sh patch from bug 2679, and to add "colorgcc" to your FEATURES. Note that bug 20356 should probably be closed as a duplicate of bug 2679, especially since its secondary request to update the Debian patches isn't needed once this ebuild gets committed.
it's not needed but i wan't that devs doesn't forget this bug
Resolving as FIXED. dev-util/colorgcc-1.3.2-r4 is in portage with the patch from this bug and the patch included on Bug #29178. If the Portage people don't mind, this clears the way for Bug #2679 to finally be cleared (old bug).
