[ccache] New release (with color) any time soon?
Hi, It's been an unusually long time since the last ccache release. I've just upgraded to Ubuntu Utopic (beta) which ships gcc-4.9 with its nice coloring support, and ccache-3.1.9 which is unable to leverage this feature. Fedora 21 is about to ship these versions, too. 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. Distros are very likely to pick up new mainstream stable releases, but are very unlikely to start cherrypicking from their git branch. Could you please consider releasing a new stable ccache in the not too distant future, like maybe in a month or two? It would be really cool if the next release of distros (e.g. Ubuntu V V 15.04) shipped the coloring feature out of the box. Thanks a lot, egmont ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] New release (with color) any time soon?
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?
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?
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
