| View previous topic :: View next topic |
| Author |
Message |
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
 Posted: Tue Aug 24, 2004 3:42 am Post subject: adding color to your gcc/configure |
 |
|
Adding support for colorgcc/grc has been requested off and on, and is an old bug-
bug #2679 (colorgcc)
bug #43046 (grc)
I'm thinking about closing these bugs out, since the potential bugs from attempting to parse gcc output doesn't sound fun. Added, there are 450+ other slightly nastier portage bugs that need attention 
So... here is how you do it unofficially.
Package masked portage-2.0.51_pre18 and above now have working support for profile.bashrc; basically this is a file that is sourced during the actual bash bits, think /etc/profile.env. The reason for it's addition was it was part of a set of changes that enabled us to fix issues for amd64 related to lib/lib64. Down the line, each profile's profile.bashrc will be sourced, currently, only /ec/portage/profile/profile.bashrc and /etc/make.profile/profile.bashrc are sourced.
Hokay, 'nuff background.
for colorgcc support
| Code: | echo 'declare -xf gcc cc' > /etc/portage/profile/profile.bashrc
echo 'gcc() { /usr/bin/wrappers/gcc $@;}' >> /etc/portage/profile/profile.bashrc
echo 'cc() { /usr/bin/wrappers/cc $@;}' >> /etc/portage/profile/profile.bashrc |
will do the trick. Note, one caveat- this doesn't work if logging is enabled, although that shouldn't be an issue down the line- the method of logging will be changed from the tee approach.
Keep in mind that this is kind of abusing ancillary functionality, so weirdo configure + (gcc|cc) bugs that pop up *need* to be tested with this disabled.
Meanwhile, enjoy. |
|
| Back to top |
|
 |
MaxAuthority
n00b
Joined: 19 Mar 2004
Posts: 18
|
| Posted: Tue Aug 24, 2004 3:59 am Post subject: cool |
|
|
Thank you VERY much.
One thing:
Is it also possible to override the ./configure command with e.g. "grc ./configure" so that we also have color while configuring with this solution?
And a last question:
Are there more subfiles in: /etc/portage/profile/
because otherwise we wouldn't need to make so deep directories, and could put profile.bashrc in /etc/portage/profile.bashrc ?
UPDATE:
Now i tested it, it seems to work, I had to add the following to profile.bashrc for grc to work:
| Code: |
declare -xf make gcc cc
make() { /usr/bin/grc -es make $@;}
gcc() { /usr/bin/grc -es gcc $@;}
cc() { /usr/bin/grc -es cc $@;}
|
(note the `make' lines).
UPDATE2:
With grc, it doesn't seem to read /root/.grc/conf.gcc, so you need to copy that to /usr/share/grc/ if you want non-default grc colors.
best regards,
Martin |
|
| Back to top |
|
|
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Tue Aug 24, 2004 6:24 am Post subject: Re: cool |
|
|
| MaxAuthority wrote: | | Thank you VERY much. |
No prob. Thank jstubbs on that one, he pointed out the possibility of just aliasing it using the profile.bashrc support I commited earlier
| MaxAuthority wrote: | One thing:
Is it also possible to override the ./configure command with e.g. "grc ./configure" so that we also have color while configuring with this solution? |
Could get away with an alias technically.
| MaxAuthority wrote: | Are there more subfiles in: /etc/portage/profile/
because otherwise we wouldn't need to make so deep directories, and could put profile.bashrc in /etc/portage/profile.bashrc ? |
Yes; /etc/portage/profile is a user defined profile; basically, instead of monkeying about in /etc/make.profile (which symlinks back to a directory in $PORTDIR/profiles), the user can specify their own profile extensions/tweaks.
Since the bashrc support was intended for -just- profiles at this point, it has to wind up in the user's area for profile extensions.
Additional thoughts- if you use this, you're saving a function into the ebuild's env; this can bite you in the ass down the line if you remove the colorgcc binaries, or they change paths (this is basically a nifty hack, course there are warts). Better function definitions to use (using colorgcc again)
| Code: | gcc() { $(type -p /usr/bin/wrappers/gcc || type -p gcc) $@; }
cc() { $(type -p /usr/bin/wrappers/cc || type -p cc) $@;} |
This induces a path lookup for each gcc call; all in all, not horrid since bash would do this anyways. The difference between this function prototype and the previous ones further up the thread is that this form is tolerant to grc/colorgcc moving their binaries, or the binaries no longer being used (eg, user tried it, disliked it, and killed it from their bashrc).
The previous form isn't. How much of an issue is this? Not much honestly. The only way it would rear it's head is if the ebuild was fooling w/ gcc/cc/make/whatnot in a (pre|post)(rm|inst).
Which is unlikely. |
|
| Back to top |
|
|
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Tue Aug 24, 2004 6:30 am Post subject: Re: cool |
|
|
Additionally, since functions are being abused, this should work with ccache/distcc.
Note the 'should'. |
|
| Back to top |
|
|
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Tue Aug 24, 2004 7:08 am Post subject: |
|
|
| Side note, use /etc/portage/bashrc rather then /etc/portage/profile/profile.bashrc... shorter path, added, /etc/portage/bashrc is intended for env tweaks (again, throw cookies at jstubbs for pointing that file out). |
|
| Back to top |
|
|
MaxAuthority
n00b
Joined: 19 Mar 2004
Posts: 18
|
| Posted: Tue Aug 24, 2004 1:58 pm Post subject: |
|
|
thanks for the tip with the alias, it now works for me with GRC and this code in my /etc/portage/bashrc:
| Code: |
declare -xf make
make() { /usr/bin/grc -es make $@;}
alias "./configure"="/usr/bin/grc -es ./configure"
|
Haven't used the 'type' trick though, since I normally remember when I edit config files, and it's too much work since I need command line arguments for grc.
Important note for grc is, that I hade some compiler (or rather configure) errors when I set the lines:
| Code: |
gcc() { /usr/bin/grc -es gcc $@;}
cc() { /usr/bin/grc -es cc $@;}
|
but with overriding make() only it seems to work like a charm after about 5 test emerges.
Also important is, that you must have the grc config files in:
/usr/share/grc/conf.gcc
/usr/share/grc/conf.configure
rather than your or root's home dir.
You can get some good example configs from:
https://bugs.gentoo.org/show_bug.cgi?id=43046
Hope that helps for everyone which tries to set up grc with emerge. |
|
| Back to top |
|
|
MaxAuthority
n00b
Joined: 19 Mar 2004
Posts: 18
|
| Posted: Tue Aug 24, 2004 4:04 pm Post subject: |
|
|
hmm, didn't work as expected though with all programs.
E.g. 'emerge zsh' exited with these errors:
| Code: |
# Not a target:
yodl2txt:
# Command-line target.
# Implicit rule search has not been done.
# Modification time never checked.
# File has not been updated.
# files hash-table stats:
# Load=5/1024=0%, Rehash=0, Collisions=0/5=0%
# VPATH Search Paths
# No `vpath' search paths.
# No general (`VPATH' variable) search path.
|
EDIT:
alias "make"="/usr/bin/grc -es make" in /etc/portage/bashrc didn't work either for some reason (it compiled, but not color output), finally the only way was to manually edit /usr/lib/portage/bin/emake and change:
| Code: |
make ${MAKEOPTS} ${EXTRA_EMAKE} "$@"
|
to
| Code: |
/usr/bin/grc -es make ${MAKEOPTS} ${EXTRA_EMAKE} "$@"
|
The trick with:
alias "./configure"="/usr/bin/grc -es ./configure"
worked however, don't know why aliasing "make" doesn't work though() 
I will try to search another solution, but if I don't find one I will post it to the bug report, since you seemed to be willing to maybe apply the patch |
|
| Back to top |
|
|
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Tue Aug 24, 2004 6:22 pm Post subject: |
|
|
| MaxAuthority wrote: | | hmm, didn't work as expected though with all programs. |
Now you see my reasons for not wanting this in portage proper
| MaxAuthority wrote: |
alias "make"="/usr/bin/grc -es make" in /etc/portage/bashrc didn't work either for some reason (it compiled, but not color output), |
Alias's don't seem to propogate correctly, hence the function hack.
| MaxAuthority wrote: | The trick with:alias "./configure"="/usr/bin/grc -es ./configure"
worked however, don't know why aliasing "make" doesn't work though |
if the ebuild is using emake, make is called from a seperate shell (since emake is a seperate script); the alias doesn't make it that far from what I've seen. For ./configure, either the ebuild calls ./configure directly, or it uses econf (which does the same)- this is all in the same shell, so the alias still exists/active/whatnot.
| MaxAuthority wrote: | | since you seemed to be willing to maybe apply the patch |
Not until these issues are straightened out, and I'm positive it's not hosing things up. If you're not using ccache or distcc, could use
| Code: | | export PATH="/usr/bin/wrappers:${PATH}" |
for colorgcc; probably would work better. |
|
| Back to top |
|
|
MaxAuthority
n00b
Joined: 19 Mar 2004
Posts: 18
|
| Posted: Tue Aug 24, 2004 6:47 pm Post subject: |
|
|
| ferringb wrote: |
Now you see my reasons for not wanting this in portage proper
|
ok, ok, convinced
| MaxAuthority wrote: | since you seemed to be willing to maybe apply the patch
| ferringb wrote: |
Not until these issues are straightened out, and I'm positive it's not hosing things up.
|
|
Well, I have to understand that. I will continue testing with as many ebuilds as possible (and telling about you in this forum or the bugreport about possible problems, or if everything worked fine in some days.)
But the trick with `${PREMAKE_CMD} make $*` in /usr/lib/portage/emake shouldn't mess up anything.
And moreover, this should be off by default anyways, and if there is a warning in /etc/make.conf.defaults when using PREMAKE_CMD (or FEATURE="grc", which the patch also introduces), there shouldn't be any harm to people using it.
| ferringb wrote: |
If you're not using ccache or distcc, could use
| Code: | | export PATH="/usr/bin/wrappers:${PATH}" |
for colorgcc; probably would work better. |
well, I use ccache, and also I don't really like the idea of a wrapper path, but that's just personal taste.
BTW, Thanks for hearing about user's wishes to improve portage and answering them, ferringb |
|
| Back to top |
|
|
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Tue Aug 24, 2004 7:43 pm Post subject: |
|
|
| MaxAuthority wrote: | | Well, I have to understand that. I will continue testing with as many ebuilds as possible (and telling about you in this forum or the bugreport about possible problems, or if everything worked fine in some days.) |
The less problematic this feature looks, the more likely it'll be included in portage rather then being external (unless the external method works fine, and no need for shoving it into ebuild.sh).
| MaxAuthority wrote: | But the trick with `${PREMAKE_CMD} make $*` in /usr/lib/portage/emake shouldn't mess up anything.
And moreover, this should be off by default anyways, and if there is a warning in /etc/make.conf.defaults when using PREMAKE_CMD (or FEATURE="grc", which the patch also introduces), there shouldn't be any harm to people using it. |
By default having it off won't break anything; what I'd like to avoid is causing borkage in packages when it's on- I haven't tried the ebuild.sh modifications, not sure how well they behave (I'd suspect probably a bit better then the bashrc approach).
| MaxAuthority wrote: | | BTW, Thanks for hearing about user's wishes to improve portage and answering them, ferringb |
No prob. Basically it looked like an easy thing to take care of, just needs a fair amount of testing rather then schlopping it into portage and then sorting out the ensuing bugs |
|
| Back to top |
|
|
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Wed Aug 25, 2004 3:08 am Post subject: |
|
|
Additional note- logging can be enabled w/ colorgcc (assume the same for grc)- the issue is colorgcc itself, makes a specific test to see if stdout is a tty or not.
hunt for
And adjust the test so it writes to tty's, and everything behaves fine. |
|
| Back to top |
|
|
modn
n00b
Joined: 29 Jun 2004
Posts: 28
Location: Passau, Germany
|
| Posted: Tue Nov 23, 2004 9:09 pm Post subject: |
|
|
Hello everyone!
Well, since everyone on #gentoo was just laughing about the idea of me having colorized output of ./configure, i felt the urge of posting a reply in this thread.
I have made the following changes to /etc/portage/bashrc:
| Code: | alias "./configure"="/usr/bin/grc -es ./configure"
declare -xf make
make() { /usr/bin/grc -es make $@;}
|
With the same lines in ~/.bashrc and manually configuring/compiling packages, it works fine, but as soon as I use emerge <package>, there's no color in the output of ./configure. Any ideas? |
|
| Back to top |
|
|
TrueDFX
Retired Dev
Joined: 02 Jun 2004
Posts: 1348
|
| Posted: Tue Nov 23, 2004 10:32 pm Post subject: |
|
|
Interesting thread, this. Two things worth pointing out:
- It's probably safer to replace the $@ with "$@" (including the quotes) everywhere where it's not yet quoted.
- Instead of a make function, why not just have emake colourised with an alias? | Quote: | | but as soon as I use emerge <package>, there's no color in the output of ./configure. Any ideas? |
It's possible that configure is not called directly, or not called with "./configure". Some ebuilds call configure from a separate build directory. Which package are you having problems with? Does it happen with other packages too? |
|
| Back to top |
|
|
modn
n00b
Joined: 29 Jun 2004
Posts: 28
Location: Passau, Germany
|
| Posted: Tue Nov 23, 2004 10:43 pm Post subject: |
|
|
| Quote: | | It's probably safer to replace the $@ with "$@" |
BTDT - still works, at least for make.
| Quote: | | It's possible that configure is not called directly, or not called with "./configure". |
I guess so... I've tried about 10 packages, all without color in the output of ./configure
What do I try next? |
|
| Back to top |
|
|
TrueDFX
Retired Dev
Joined: 02 Jun 2004
Posts: 1348
|
| Posted: Tue Nov 23, 2004 10:53 pm Post subject: |
|
|
| modn wrote: | | BTDT - still works, at least for make. |
$@ works most of the time. "$@" always works
And never mind my previous message. Apparently bash 3 doesn't like ./configure as an alias name, but has no problem with it as a function name. Try this: | Code: | | ./configure() { /usr/bin/grc -es ./configure "$@"; } |
|
|
| Back to top |
|
|
modn
n00b
Joined: 29 Jun 2004
Posts: 28
Location: Passau, Germany
|
| Posted: Wed Nov 24, 2004 6:29 am Post subject: |
|
|
Well, what can I say - it works!
Thanks a lot!
My /etc/portage/bashrc:
| Code: | declare -xf make configure
make() { /usr/bin/grc -es make "$@";}
./configure() { /usr/bin/grc -es ./configure "$@"; } |
|
|
| Back to top |
|
|
MaxAuthority
n00b
Joined: 19 Mar 2004
Posts: 18
|
| Posted: Sun Nov 28, 2004 4:09 pm Post subject: |
|
|
| modn wrote: | Well, what can I say - it works!
Thanks a lot!
My /etc/portage/bashrc:
| Code: | declare -xf make configure
make() { /usr/bin/grc -es make "$@";}
./configure() { /usr/bin/grc -es ./configure "$@"; } |
|
I did the same, and it worked for most things.
However, when doing an 'emerge nvidia-kernel' (=version 6629), it failed.
| Code: |
NVIDIA: calling KBUILD...
make CC=gcc KBUILD_VERBOSE=1 -C /usr/src/linux M=/var/tmp/portage/nvidia-kernel-1.0.6629/work/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv modules
mkdir -p /var/tmp/portage/nvidia-kernel-1.0.6629/work/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/.tmp_versions
make -f scripts/Makefile.build obj=/var/tmp/portage/nvidia-kernel-1.0.6629/work/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv
echo \#define NV_COMPILER \"`gcc -v 2>&1 | tail -n 1`\" > /var/tmp/portage/nvidia-kernel-1.0.6629/work/NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/nv_compiler.h
make[3]: *** read jobs pipe: No such file or directory. Stop.
make[3]: *** Waiting for unfinished jobs....
|
after I removed these 3 lines, it worked again. Does somebody else encounter the same problem?
however:
| Code: |
/usr/bin/grc -es make ${MAKEOPTS} ${EXTRA_EMAKE} "$@"
|
in my /usr/lib/portage/bin/emake works instead of:
| Code: |
make ${MAKEOPTS} ${EXTRA_EMAKE} "$@"
|
|
|
| Back to top |
|
|
BikE
Guru
Joined: 21 Dec 2004
Posts: 455
Location: Genova
|
| Posted: Sat Jan 07, 2006 6:35 pm Post subject: |
|
|
Hei man i've try to do that.... this is my /etc/profile/bashrc:
| Code: |
declare -xf make configure
gcc() { /usr/lib/colorgcc/bin/gcc $@; }
./configure() { /usr/bin/grc -es ./configure "$@"; }
cc() { /usr/lib/colorgcc/bin/cc $@; }
make() { /usr/bin/grc -es make $@;}
|
But all my emerge fails with
| Code: |
Traceback (most recent call last):
File "/usr/bin/grcat", line 127, in ?
m = pattern['regexp'](line, pos)
OverflowError: signed integer is greater than maximum
|
Is a make function error cause the configure finish without error.... i'm on AMD64.... any ideas??? |
|
| Back to top |
|
|
flithm
n00b
Joined: 05 Jul 2006
Posts: 1
|
| Posted: Wed Jul 05, 2006 8:46 pm Post subject: Works for me |
|
|
I've had good results changing "/usr/lib/portage/bin/emake" from:
| Code: | | exec ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@" |
to:
| Code: | | exec grc ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@" |
All of the alias and related tricks (revolving around colorizing ./configure) seem to eventually cause problems and should be avoided. For now I think the best thing to do is to stick with colored compiles until official support for colorizing configures can be added.
Everyone who's interested in this please submit a comment to the official bug: https://bugs.gentoo.org/show_bug.cgi?id=43046
It's such an easy feature to add, but keeps getting overlooked. |
|
| Back to top |
|
|
grrrendel
n00b
Joined: 02 Jan 2007
Posts: 4
|
| Posted: Tue Jan 02, 2007 4:56 pm Post subject: |
|
|
| BikE wrote: | But all my emerge fails with
| Code: |
Traceback (most recent call last):
File "/usr/bin/grcat", line 127, in ?
m = pattern['regexp'](line, pos)
OverflowError: signed integer is greater than maximum
|
Is a make function error cause the configure finish without error.... i'm on AMD64.... any ideas??? |
I had the same errors on amd64. However, they went away with grc-1.0.8 (see this bug). |
|
| Back to top |
|
|
vfikov
n00b
Joined: 11 Jan 2014
Posts: 4
Location: Sofia, Bulgaria
|
| Posted: Sun Jan 12, 2014 9:16 am Post subject: Hi guys! |
|
|
Hi guys!
Any updates here?
Is there any way to apply colorization for >=portage-2.2.8 ?
Thanks! |
|
| Back to top |
|
|
|
Portage & Programming
