I really enjoy using grc to colorize my builds and configures. I made a few small modifications to the portage 2.0.50-r1 source which allows the use of 'grc' as one of the FEATURES defined in make.conf. When grc is defined as a FEATURE, emerge will colorize all configure and make's. Who needs xscreensaver. I also have a set of customized grc configuration files which allow for configure to be colorized, and which make the colorization of gcc look 'nicer'. I am not certain of the correct procedure for submitting these patches, so I have pasted them into the Additional Information field. If this is incorrect, I will be happy to post them again in another manner. Reproducible: Always Steps to Reproduce: I will glady send the patches to any location / address. For now here they are: ##################### ## Patch for ebuild.sh ##################### --- portage-grc/ebuild.sh 2004-02-26 17:43:43.675248260 -0700 +++ portage-2.0.50-r1/bin/ebuild.sh 2004-02-09 08:57:32.000000000 -0700 @@ -353,7 +353,7 @@ if [ ! -z "${CBUILD}" ]; then EXTRA_ECONF="--build=${CBUILD} ${EXTRA_ECONF}" fi - $CONFIGURE_CMD ./configure \ + ./configure \ --prefix=/usr \ --host=${CHOST} \ --mandir=/usr/share/man \ @@ -1229,16 +1229,6 @@ export USER=portage fi - # GRC support for fun colorized builds and configures! - if has grc ${FEATURES} &>/dev/null; then - if [ -f /usr/bin/grc ]; then - CONFIGURE_CMD=${CONFIGURE_CMD//grc /""} - MAKE_CMD=${MAKE_CMD//grc /""} - export CONFIGURE_CMD="grc $CONFIGURE_CMD" - export MAKE_CMD="grc $MAKE_CMD" - fi - fi - if has distcc ${FEATURES} &>/dev/null; then if [ -d /usr/lib/distcc/bin ]; then #We can enable distributed compile support @@ -1253,7 +1243,7 @@ export CXX="distcc $CXX" fi fi - + if has ccache ${FEATURES} &>/dev/null; then #We can enable compiler cache support if [ -z "${PATH/*ccache*/}" ]; then ##################### ## Patch for emake ##################### --- portage-grc/emake 2004-02-26 17:43:46.987427593 -0700 +++ portage-2.0.50-r1/bin/emake 2003-02-22 09:59:08.000000000 -0700 @@ -11,4 +11,4 @@ # /etc/make.globals here because emake is only called from an # ebuild. -$MAKE_CMD make ${MAKEOPTS} ${EXTRA_EMAKE} "$@" +make ${MAKEOPTS} ${EXTRA_EMAKE} "$@" ##################### ## Patch for grc.conf ##################### --- /etc/grc.conf 2004-02-26 17:10:26.191696895 -0700 +++ grc-1.0.6/grc.conf 2002-08-18 11:39:23.000000000 -0600 @@ -15,21 +15,13 @@ conf.traceroute # gcc command -#(^|[/\w\.]+/)g?cc\s -#conf.gcc +(^|[/\w\.]+/)g?cc\s +conf.gcc # make command -#(^|[/\w\.]+/)g?make\s? -#conf.gcc - -# gcc/make command -(sudo )?(g?cc|g?make|g?\+\+) +(^|[/\w\.]+/)g?make\s? conf.gcc -# configure command -(^|[/\w\.]+/)configure -conf.configure - # netstat command (^|[/\w\.]+/)netstat\s? conf.netstat ##################### ## Patch for conf.gcc in /usr/share/grc/ ##################### --- /usr/share/grc/conf.gcc 2004-02-26 16:51:36.431956976 -0700 +++ grc-1.0.6/conf.gcc 1999-11-22 12:52:08.000000000 -0700 @@ -1,10 +1,10 @@ # -regexp=\b(g?cc|[gc]\+\+|g?as|ld)\b -colours=white bold -count=once +regexp=\bgcc\b +colours=yellow +count=more ......... # -regexp=^\S*: +regexp=^.*?: colours=red count=once ......... @@ -12,51 +12,22 @@ regexp=\`\w+\' colours=green ......... -# compilation method modifiers -regexp=\s\-(O\d?|f\S+|pthread|g\S*|c|W\S,\S+)\b -colours=yellow -......... -# source file name -regexp=\s[^-]\S*\.(c|C|cc|c[x\+p]{2,2}|m|o|a|s)\b +# -O +regexp=\-O\d colours=green ......... # -o -regexp=\-o\s+\S+ -colours=green bold -count=once -......... -# -W... or -w -regexp=\s\-(W\S[^,]\S*|w\b) -colours=blue -......... -# -D... -regexp=\s\-D\S+ -colours=blue bold -......... -# -I... -regexp=\s\-I[^- ]\S* -colours=cyan -......... -# -I- -regexp=\s\-I\- -colours=cyan bold -......... -# -L... -regexp=\s\-L\S* -colours=magenta -......... -# -l... -regexp=\s\-l\S+ -colours=magenta bold +regexp=\-o\s.+\b +colours=yellow ......... # warning and error won't work, unless you redirect also # stderr to grcat # # warning -regexp=[Ww]arning[:\b] -colours=yellow bold +regexp=warning +colours=yellow ......... # error -regexp=[Ee]rror[:\b] +regexp=error colours=red blink count=stop ##################### ## New file /usr/share/grc/conf.configure ##################### # cache functions regexp=\b(loading|updating|creating) cache\b colours=yellow bold ......... # checking regexp=\bchecking\s*(for|if|whether|command|how|that)?(\s*to)?\b colours=yellow ......... # result is complex regexp=\.\.\. .*$ colours=cyan ......... # check succeeded regexp=\.\.\.( \(cached\))? yes$ colours=blue bold ......... # check did not succeed regexp=\.\.\.( \(cached\))? no$ colours=magenta ......... # ... should be normal regexp=\.\.\. colours=default ......... # creating stuff regexp=\bcreating\b colours=green
Created attachment 26436 [details, diff] Patch for ebuild.sh to allow colorization of builds and configures via grc
Created attachment 26437 [details, diff] Patch to emake which alows colorization via grc
Created attachment 26438 [details, diff] Patch to grc.conf which allows makes AND configures to be colorized
Created attachment 26439 [details, diff] Patch to the grc gcc colorization which makes colors 'nicer'. File is located in /usr/share/grc/
i'd just as soon mark this a dup of Bug 2679 but i'd imagine someone might throw a stink
Created attachment 26440 [details] additional grc configure file which specifies color mapping for ./configures
grc is much better than colorgcc. Not only does it color gcc builds, but anything, including configures. Which is much nicer. grc was, in fact, inspired by the likes of colorgcc. Apologies for the nasty cut 'n paste. I didn't know how the system worked.
Yes, grc is much more advanced than colorgcc, so I wouldn't say it's a duplicate of 2679. And thanks for the ./configure color script. If we now could only have this for portage apps as well, not only for self compiled apps. Hopefully, this patch gets accepted soon.
I actually posted patches for portage that enabled colorized emerges (including configures and makes), but no one did anything with them. Of course the patches are out of date now, since it's been so long. It took me a while to create those patches since I had to partially figure out how portage was written, but I would think someone on the portage team could have done it in 15 minutes. All my emerge's were nicely colorized until the next update of portage came down the line and blew away all my changes. Now I'm back to black 'n white. :o(. I don't understand why this is such a low priority for them!? Especially when compiling a long build (kde), it's so much nicer (and cooler!) to have the output colorized. I also think it would be a little bit of a selling feature for the distro. Imagine your debian buddy comes over and sees you installing a new app. He'd be like, WHOA SWEET your gcc output is in color! I don't think a lot of people know about grc. Actually come to think of it the Gentoo team itself hasn't been very receptive to input. I've created ebuilds, submitted patches, and all to almost no avail. I know other people have expressed similar opinions as well. It's frustrating since Gentoo is such a good distro.
@Tim: if you don't follow the forums (I normally don't do either, it was pure luck), look at this brand new thread: http://forums.gentoo.org/viewtopic.php?t=213596 it shows how to use grc in the latest versions of portage. To your complaint about gentoo devs not accepting patches/listening to users: I heard this complaint from others as well and hopefully it's not that bad in future, that people get angry about gentoo. Because Gentoo is still by far the best distro I know, but well, things could always be even better :) I understand that often accepting/testing patches is a lot of work, but in this case it's actually just 10 lines in 2 core portage files (the conf.{gcc,configure} files are nice, but not essential, because they can be user created, without being overwritten after reemerging portage) which need to be changed.
"http://forums.gentoo.org/viewtopic.php?t=213596 it shows how to use grc in the latest versions of portage." I started that thread due to tim generating traffic on this bug; keep in mind we have 400+ portage bugs. It's *very* easy to miss the needle in the haystack. It's not intentional, but a lot of the minor fixes/features have plain been overlooked/ignored/dropped unless they were utterly critical. Generating noise on a bug (as you did, and lead to that thread) is a good way to get people to look at it; note that noise != flaming (although flaming is more entertaining):) Re: accepting patches/listening to users- You're not the only one who has suffered patch-rot in bugs.g.o; I have around a month of portage modifications sitting currently, although now it's sitting since it should be included post-.51. May not be visible, but the general consensus seems to be portage development is starting to accelerate a bit. Additionally, bantering around the 'lots of open bugs' excuse... well, we have lots of open bugs, most quite a bit more critical then adding color support (broken behaviour fex). Meanwhile, back to the bug. I'm not much for adding this into portage- I'd rather the bashrc trick be used, although if users find it useful, I spose I could slip it in. This would be down the line; as is, the bashrc trick works for everything but when the user has PORT_LOGDIR enabled, although that issue should go away in the near future.
Thanks for the response :o). The bashrc trick is great, although the only problem I see with it is that it doesn't appear to work with colorizing the ./configure output (which is not only cool, but really helpful), as you can easily pick out the "no" and "yes" responses, to make sure you've got all your USE vars set correctly. Also if you're writing your own ebuilds it can help to make sure you've got your dependencies correct. At any rate if there's a way configure scripts can work using the bashrc trick, I'm all for it! I couldn't get it to work because it runs as `./configure` (as opposed to just `configure`) which I guess is different, although I didn't try a lot of different things so maybe it is possible after all? I know you're not totally for putting it directly into portage, but if the bashrc trick doesn't work with configure, I would still like to see it in there. And I think if it's implemented as an optional FEATURE (in make.conf) much like distcc or the other FEATURE's there's no reason why it has to be problematic. For people who don't like it they can just leave that FEATURE out. Just my .02 dollars.
Ahh, I just noticed that there has been some development on colorizing ./configure as well using an alias. It appears to me though that this solution is somewhat sub-optimal, as seen by problems reported by MaxAuthority on the forum thread. My vote is to still include this in portage itself as, if done correctly there, it will work 100%. On the other hand, if the bugs get ironed out with the bashrc/alias trick I'll be more than happy to accept that as well.
added some of these tweaks to the grc ebuild and e-mailed them upstream
i have used this combination of grc and portage for 2 months now, and just want to confirm, that i didn't have any problems with the combination of setting: alias "./configure"="/usr/bin/grc -es ./configure" in /etc/portage/bashrc and /usr/bin/grc -es make ${MAKEOPTS} ${EXTRA_EMAKE} "$@" in /usr/lib/portage/bin/emake . The first one can be done with the current portage system, but I really opt for adding something like a MAKECMD variable in /etc/make.conf, so that you don't need to patch the emake file every time you update portage. As I said before, I used this combination for 2 months with dozens of ebuilds now, without any problems.
I can confirm that this is the only method that works so far. There is a previously mentioned method that came from the forums which entirely uses alias's and various tricks in /etc/portage/bashrc. That method DOES NOT WORK in all cases. It would be nice to see the above method implemented with a flag added in make.conf to allow users to specify whether or not they want colorization. I know that portage developers have been leary of adopting any sort of colorization patches, however I emplore them to test the above method. It does work, and does not produce errors.
this is cool. especially useful for spying warnings that would otherwise slip by on a large build. i just wanted to chime in and say that this: declare -xf make configure make() { /usr/bin/grc -es make "$@";} ./configure() { /usr/bin/grc -es ./configure "$@"; } ends up giving errors like this (tar-1.15.1): checking whether make sets $(MAKE)... ./configure: line 1643: ac_maketemp=make: command not found no moving make to /usr/lib/portage/bin/emake like mentioned above allows it to give the correct response.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Any chance we could revisit this? I know that some people are against the colorizing of gcc in portage because of the potential for additional problems. As far as I can tell the only problems come into play when employing aliases or other tricks (usually to get ./configure's colorized as well). I've been testing colorizing builds by changing /usr/lib/portage/bin/emake from: exec ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@" to: exec grc ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@" I've never had an ebuild die or any other problem occur as a reslut of this. And if you ask me it greatly enhances portage's coolness factor. It's such a simple thing, and has the potential to bring so much joy to so many people :). I think it should be considered. At least for colorizing gcc. Perhaps configure coloring can come later, until a better method can be found).
Uhm, can't you just set $MAKE to grc (or a wrapper script that calls the right thing) and be done? I'd really want to avoid any special support for 3rd party tools when it's not necessary.
I hadn't thought of that... I always assumed that portage was using that variable internally. I tested setting $MAKE to "grc make" and it definitely works, however I still think it would be cool to add official support for it. If it were a FEATURE available in make.conf I think a lot of people would use it. And it's not like it's a difficult thing to add. Plus, there's also support for tons of third party tools, like ccache, distcc, etc. Another thing that would be nice is a similar way to colorize the configure scripts with grc. Is there a variable similar to $MAKE that portage uses?
I revisted ebuild.sh and noted that it'll take changing 4 or 5 lines to add support for colorizing configures but it doesn't look difficult. If I were to make a proper patch with the necessary changes (add a FEATURE in make.conf and conditionally use grc to colorize both configures and compiles) would this be something that the portage team would consider including?
(In reply to comment #21) > Plus, there's also support for tons of third party tools, like ccache, distcc, > etc. Those add essential functionality which it is really worth supporting them. I somehow lack to see how colorized output is going to improve anything. You say that if there was a FEATURE for it, lots of people would use it. I doubt that: Who looks at emerge's output anyway? Beside that, this bug is really old and still has noone on CC, which usually means there aren't a lot of people who really care about it.
Hmmm... point taken :). I suspect that most people aren't aware you can colorize the gcc output. I know it doesn't add significant functionality. I just think it's cool, and very much in the spirit of gentoo itself. When I emerge packages I always have the output up on a second monitor. And I know it's not just me that's interested. There's a few people that replied to this thread, and there was some other people interested on the forum post. I also remember seeing more than one bug opened regarding colorgcc (which btw is not a good way to go -- grc is much better). It's such a small change, like 5 or 6 lines of code probably, and although it's only cosmetic, you have to admit color is generally much cooler than black and white :). It's not like it adds any real complexity to portage, and if it's something that people can turn on and off easily why not?
(In reply to comment #21) > Plus, there's also support for tons of third party tools, like ccache, distcc, > etc. Well, this "support" deals mainly with applying permissions and actually I'd prefer to move that out into the gcc wrapper (as IMO this is a general toolchain thing), see bug #128810 As for configure, might be useful to come up with a way to specify wrappers for that too to allow this and move confcache support out of portage (if possible). I'm quite reluctant about adding more FEATURES (that var is bloated enough already IMHO) if there are other ways to get things done. Closing as setting $MAKE solves it, adding support for $CONFIGURE would be another bug.
Okay this makes sense to me. Adding the ability to have a wrapper for configure commands would solve my problem too. I'll open a new bug for $CONFIGURE.
*** Bug 139418 has been marked as a duplicate of this bug. ***
maybe i write this in wrong topic ? but i have this bug: [root]::[dupoliz]/var/log# traceroute wp.pl 22:20 Traceback (most recent call last): File "/usr/bin/grc", line 110, in <module> os.execvp(args[0], args) File "/usr/lib/python2.5/os.py", line 354, in execvp _execvpe(file, args) File "/usr/lib/python2.5/os.py", line 380, in _execvpe func(file, *argrest) OSError: [Errno 2] No such file or directory
definitely the wrong place.
