Re: [ccache] does ccache include source code modified time into hash?
On Thu, Nov 13, 2014 at 2:27 PM, Andrew Stubbs a...@codesourcery.com wrote: Probably there was a timestamp in a generated header somewhere. Another similar issue might be if you embed the build ID (the git commit ID) in some weird way, like e.g. midnight commander does, so that every tiny git commit causes a total loss of the cache. e. ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
[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, 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
[ccache] Why not using MD5?
On Mon, Nov 15, 2004 at 06:25:49PM +1100, Martin Pool wrote: The other factor is whether the cache will grow to include a million files. We're building a distribution using a build system completely created by us and it intensively uses ccache. We have approx 1000 packages, including, of course, all the standard linux applications. Through about 1.5 years we've had one huge ccache pool for all our packages and sometimes manually dropped old files after a change that caused old files not to match anymore (gcc, glibc etc. upgrade). The ccache size was around 5-10 GB. Recently we changed to use separate pool for each package, but for other reasons, not because we've met any collision. Fortunately we didn't meet any, but I didn't even realize that we've been not far from it... (If you're curious I can easily count the number of entries in our ccache pools later this day.) So there's one more vote here for md5. It doesn't hurt if ccache is prepared for extreme use. :-)) And it's perfect time to do it now since the 2.4-2.5 version number change would reflect the md4-md5 change :- PS. AFAIK no-one has ever found two different files with the same md5. Am I right? bye, Egmont
