Re: [ccache] New release (with color) any time soon?

2014-10-18 Thread Paul Smith
On Sat, 2014-10-18 at 13:24 +0200, Egmont Koblinger wrote:
 Coloring support has been in ccache git for almost a year now.  I've just
 simply compiled and installed it, overwriting Ubuntu's package, and it
 works like a charm for me.

Can someone describe the ccache support for this?  I wonder how it might
(or might not) interact with GNU make's method of determining whether
there's a controlling TTY, in cases where make's output synchronization
is enabled.

___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] New release (with color) any time soon?

2014-10-18 Thread Egmont Koblinger
On Sat, Oct 18, 2014 at 7:23 PM, Paul Smith p...@mad-scientist.net wrote:


 Can someone describe the ccache support for this?  I wonder how it might
 (or might not) interact with GNU make's method of determining whether
 there's a controlling TTY, in cases where make's output synchronization
 is enabled.


I'm really not the right guy to answer this, but here's what I believe
happens (after playing a bit with ccache+colors and taking a glimpse at the
patch that introduced this feature, and also quickly checking make's
--output-sync now).

The most important thing is that ccache should always remain totally
transparent, and this is guaranteed with coloring too.  ccache figures out
what kind of coloring gcc would use if it was called directly (rather than
via ccache), depending on whether the stdout/err is a tty, on
-f(no-)diagnostics-color=xx and $GCC_COLORS.  It includes all these values
in the hash(*) and forces gcc to use color if necessary (because the actual
gcc's output is not a tty).

(*) This means that if you perform the same complications with tty output
(colors enabled) and with redirected output (no colors), it won't share the
cache. This causes some performance regression in case you first do a
colored gcc to your tty, but upon seeing tons of errors you decide to run
gcc | less to examine them. Also if you alter GCC_COLORS you won't get
any cache hits.

(Theoretically, ccache could instead always invoke gcc by forcing one
particular color set where every kind of message has a different color, and
then do a search-replace to the actual runtime colors or no colors; then it
could share cache results. That would be the more conventional and better
stacking order: caching below, coloring above. I understand it's harder to
implement/maintain and the benefits would be quite low compared to the
current solution.)

make's --output-sync causes gcc (without ccache) not to use any coloring by
default (since gcc's output is not a tty but a pipe or tmpfile to make),
and having ccache in front of gcc doesn't change this.  You might specify
-fdiagnostics-color=always in your Makefile, again, I believe the presence
of ccache should be transparent and you'd get colors.

Don't trust me blindly, I might be wrong in anything I said above :)


egmont
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache


Re: [ccache] New release (with color) any time soon?

2014-10-18 Thread Egmont Koblinger
s/complications/compilations/

On Sat, Oct 18, 2014 at 7:46 PM, Egmont Koblinger egm...@gmail.com wrote:

 On Sat, Oct 18, 2014 at 7:23 PM, Paul Smith p...@mad-scientist.net
 wrote:


 Can someone describe the ccache support for this?  I wonder how it might
 (or might not) interact with GNU make's method of determining whether
 there's a controlling TTY, in cases where make's output synchronization
 is enabled.


 I'm really not the right guy to answer this, but here's what I believe
 happens (after playing a bit with ccache+colors and taking a glimpse at the
 patch that introduced this feature, and also quickly checking make's
 --output-sync now).

 The most important thing is that ccache should always remain totally
 transparent, and this is guaranteed with coloring too.  ccache figures out
 what kind of coloring gcc would use if it was called directly (rather than
 via ccache), depending on whether the stdout/err is a tty, on
 -f(no-)diagnostics-color=xx and $GCC_COLORS.  It includes all these values
 in the hash(*) and forces gcc to use color if necessary (because the actual
 gcc's output is not a tty).

 (*) This means that if you perform the same complications with tty output
 (colors enabled) and with redirected output (no colors), it won't share the
 cache. This causes some performance regression in case you first do a
 colored gcc to your tty, but upon seeing tons of errors you decide to run
 gcc | less to examine them. Also if you alter GCC_COLORS you won't get
 any cache hits.

 (Theoretically, ccache could instead always invoke gcc by forcing one
 particular color set where every kind of message has a different color, and
 then do a search-replace to the actual runtime colors or no colors; then it
 could share cache results. That would be the more conventional and better
 stacking order: caching below, coloring above. I understand it's harder to
 implement/maintain and the benefits would be quite low compared to the
 current solution.)

 make's --output-sync causes gcc (without ccache) not to use any coloring
 by default (since gcc's output is not a tty but a pipe or tmpfile to make),
 and having ccache in front of gcc doesn't change this.  You might specify
 -fdiagnostics-color=always in your Makefile, again, I believe the presence
 of ccache should be transparent and you'd get colors.

 Don't trust me blindly, I might be wrong in anything I said above :)


 egmont

___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache