tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: clang pickiness, -Werror, and macros (blows up with pkgin)

David Sainty <> 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:
> 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

Home | Main Index | Thread Index | Old Index