David Sainty <david.sainty%gmail.com@localhost> writes: > On 28/09/15 13:09, Greg Troxel wrote: >> It seems the problem is that ccache and clang interact badly, where the >> warnings that should be disabled during preprocessing are active, >> because of how ccache behaves. Arguably this is ccache's fault: >> >> http://petereisentraut.blogspot.com/2011/09/ccache-and-clang-part-2.html >> http://peter.eisentraut.org/blog/2014/12/01/ccache-and-clang-part-3/ > > I see ccache doesn't claim to be compatible with anything but gcc, so > it's arguably our fault, for allowing ccache and clang to be selected > together :) These days, it's buggy of ccache not to work with normal compilers.... But I see your point. >> So I am thinking that we should either export CACHE_CPP2 or patch ccache >> to default to doing that, because ccache seems broken without it. This >> is apparently only an issue with clang, but only because gcc doesn't >> have warnings only for non-preprocessed code. > > According to your links there's a hefty 10% run-time penalty to doing > that, which it would be mean to incur for gcc builds. We could turn on that variable when ccache is chained to clang. Or perhaps to anything but gcc. It seems only an accident that gcc has no warnings that are disabled for preprocessor output. I hadn't thought of this before, but macros tend to generate redundant code (and often should, for safety in unknown conditions). So it's not really clear to me that building with ccache and gcc (without CACHE_CPP2) is sound. Do you use ccache with gcc? I tend to use it on most systems, and haven't timed it when building new packages. But doing rebuilds after minor updates, it definitely makes things a lot faster.
Attachment:
pgpDb4F2TQaWO.pgp
Description: PGP signature