Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
adding color to your gcc/configure
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Tue Aug 24, 2004 3:42 am    Post subject: adding color to your gcc/configure Reply with quote

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. :)
_________________
I don't want to be buried in a pet cemetery. ~Ramones
Back to top
View user's profile Send private message
MaxAuthority
n00b
n00b


Joined: 19 Mar 2004
Posts: 18

PostPosted: Tue Aug 24, 2004 3:59 am    Post subject: cool Reply with quote

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
View user's profile Send private message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Tue Aug 24, 2004 6:24 am    Post subject: Re: cool Reply with quote

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.
_________________
I don't want to be buried in a pet cemetery. ~Ramones
Back to top
View user's profile Send private message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Tue Aug 24, 2004 6:30 am    Post subject: Re: cool Reply with quote

Additionally, since functions are being abused, this should work with ccache/distcc.
Note the 'should'.
_________________
I don't want to be buried in a pet cemetery. ~Ramones
Back to top
View user's profile Send private message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Tue Aug 24, 2004 7:08 am    Post subject: Reply with quote

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).
_________________
I don't want to be buried in a pet cemetery. ~Ramones
Back to top
View user's profile Send private message
MaxAuthority
n00b
n00b


Joined: 19 Mar 2004
Posts: 18

PostPosted: Tue Aug 24, 2004 1:58 pm    Post subject: Reply with quote

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:
http://bugs.gentoo.org/show_bug.cgi?id=43046

Hope that helps for everyone which tries to set up grc with emerge.
Back to top
View user's profile Send private message
MaxAuthority
n00b
n00b


Joined: 19 Mar 2004
Posts: 18

PostPosted: Tue Aug 24, 2004 4:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Tue Aug 24, 2004 6:22 pm    Post subject: Reply with quote

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.
_________________
I don't want to be buried in a pet cemetery. ~Ramones
Back to top
View user's profile Send private message
MaxAuthority
n00b
n00b


Joined: 19 Mar 2004
Posts: 18

PostPosted: Tue Aug 24, 2004 6:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Tue Aug 24, 2004 7:43 pm    Post subject: Reply with quote

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 :)
_________________
I don't want to be buried in a pet cemetery. ~Ramones
Back to top
View user's profile Send private message
ferringb
Developer
Developer


Joined: 03 Apr 2003
Posts: 355
Location: USA

PostPosted: Wed Aug 25, 2004 3:08 am    Post subject: Reply with quote

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
Code:
-t STDOUT

And adjust the test so it writes to tty's, and everything behaves fine.
_________________
I don't want to be buried in a pet cemetery. ~Ramones
Back to top
View user's profile Send private message
modn
n00b
n00b


Joined: 29 Jun 2004
Posts: 28
Location: Passau, Germany

PostPosted: Tue Nov 23, 2004 9:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
TrueDFX
Retired Dev
Retired Dev


Joined: 02 Jun 2004
Posts: 1348

PostPosted: Tue Nov 23, 2004 10:32 pm    Post subject: Reply with quote

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
View user's profile Send private message
modn
n00b
n00b


Joined: 29 Jun 2004
Posts: 28
Location: Passau, Germany

PostPosted: Tue Nov 23, 2004 10:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
TrueDFX
Retired Dev
Retired Dev


Joined: 02 Jun 2004
Posts: 1348

PostPosted: Tue Nov 23, 2004 10:53 pm    Post subject: Reply with quote

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
View user's profile Send private message
modn
n00b
n00b


Joined: 29 Jun 2004
Posts: 28
Location: Passau, Germany

PostPosted: Wed Nov 24, 2004 6:29 am    Post subject: Reply with quote

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
View user's profile Send private message
MaxAuthority
n00b
n00b


Joined: 19 Mar 2004
Posts: 18

PostPosted: Sun Nov 28, 2004 4:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
BikE
Guru
Guru


Joined: 21 Dec 2004
Posts: 455
Location: Genova

PostPosted: Sat Jan 07, 2006 6:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
flithm
n00b
n00b


Joined: 05 Jul 2006
Posts: 1

PostPosted: Wed Jul 05, 2006 8:46 pm    Post subject: Works for me Reply with quote

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: http://bugs.gentoo.org/show_bug.cgi?id=43046

It's such an easy feature to add, but keeps getting overlooked.
Back to top
View user's profile Send private message
grrrendel
n00b
n00b


Joined: 02 Jan 2007
Posts: 4

PostPosted: Tue Jan 02, 2007 4:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
vfikov
n00b
n00b


Joined: 11 Jan 2014
Posts: 4
Location: Sofia, Bulgaria

PostPosted: Sun Jan 12, 2014 9:16 am    Post subject: Hi guys! Reply with quote

Hi guys!

Any updates here?
Is there any way to apply colorization for >=portage-2.2.8 ?

Thanks!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum