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

Egmont Koblinger egmont at gmail.com
Sat Oct 18 11:50:17 MDT 2014


s/complications/compilations/

On Sat, Oct 18, 2014 at 7:46 PM, Egmont Koblinger <egmont at gmail.com> wrote:

> On Sat, Oct 18, 2014 at 7:23 PM, Paul Smith <paul at 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
>


More information about the ccache mailing list