[ccache] Bug with clang

Éric Chamberland Eric.Chamberland at giref.ulaval.ca
Sun Mar 13 02:30:21 UTC 2016



Le 16-03-12 12:15, Anders Björklund a écrit :
> Eric Chamberland wrote:
>
>> We are happy using ccache with clang but I just discovered today that
>> ccache hides documentation warnings!
> [...]
>> My CC* environment variables:
>>
>> CCACHE_SLOPPINESS=include_file_mtime
>> CCACHE_DIR=/home/ccache/cmpbib/ccache
>> CCACHE_CPP2=yes
>> CCACHE_HARDLINK=1
>> CCACHE_HASHDIR=
>>
>> How can I retrieve the documentation warnings with ccache?  Do I do
>> something wrong?
> Hmm, since you are using CCACHE_CPP2=1 you *should* be getting
> source-level warnings too. However, if you cached the previous
> result without using that setting (CCACHE_CPP2) you could still
> get the cached results, i.e. the one without the extra warnings.
>
> But it is strange because CCACHE_CPP2 should be in the hash now.
> Could be a bug with direct mode perhaps, that it never runs cpp.
> It only looks at the (unchanged) files, and returns the cache...
> If you clear the cache (or CCACHE_NODIRECT=1), does it remain ?
ok, you are right.  I did many tries before writing the mail... and 
before finding your below mentioned web page, I tried without CCACHE_CPP2...

Now, if I take care of doing a ccache -C before each configuration 
change, I can observe the warnings with ccache... So it was in fact 
cached when I tried the test and gave you the output...

However, as pointed in my previous mail, the comments are not into the 
hash, then if I compile foo.cc with ccache and get the 3 warnings, then 
modify the documentation *without* changing the number of lines (ie: 
just change "\param" by "\note"), then the output is taken from the 
previous cached compilation... :/

>
> I can reproduce your problem without CCACHE_CPP2 (due to the .ii)
> but I cannot reproduce it with CCACHE_CPP2 (when using the .cc) ?
> Your suggestion to use -C with the -E is interesting, though you
> would still get your macros expanded in warnings - and such*.
>
> * http://peter.eisentraut.org/blog/2014/12/01/ccache-and-clang-part-3/
>
> So maybe only keeping comments is not enough, full source is needed ?
For us, we compile with -Weverything, which is a lot more severe into 
the analysis.  We have to silent many warnings with "-Wno-*" options, 
but it is our burden to keep the code compiling "correctly", meaning 
absolutely no warnings.

We have recently moved to use clang to check for documentation warnings 
too, to keep us from inserting new "bad" documentation... but we are 
used to compile with ccache+icecream or ccache alone (in our nightly 
tests and continuous integration) and don't want to work without 
ccache... it is unthinkable!!!! :)

So, for me, the "keep comments" option, automated or not, is something I 
would try for sure, even if I have to compile a specific branch/sha of 
ccache... :)
>
> And maybe how to use ccache with clang should be better documented ?
Maybe... can't tell... I found your page as soon as I googled for "clang 
ccache"... :)
> It was only recently that the clang tests were fixed (396df7e), so it
> seems like most developers are using gcc - and thus that is assumed.
> I think we will see more things like this with GCC 5 (and later) too,
> so some extra lines about source-level warnings are probably needed...
We use also gcc and ICC, but clang is there to help us write better 
code... and documentation now... almost... :)
> For now, the best workaround here is the "run_second_cpp" config.
Done! :)

Thanks!

Eric

>
> /Anders
> _______________________________________________
> ccache mailing list
> ccache at lists.samba.org
> https://lists.samba.org/mailman/listinfo/ccache




More information about the ccache mailing list