Éric Chamberland wrote: >>> 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... :/
Yeah, obviously I didn't think that one through completely :-) For the hash to work (or rather: not work), then the preprocessor needs to keep the comments in. Normally those don't affect the object file, and discarding them is a feature - you get cache hits when you only change a comment that doesn't affect the .o output. But if you are using something like Doxygen, you do get output. Later. And it does of course affect the .stderr output, that you were after. >> 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. Seems like both could be useful... (available as separate options) > 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... :) I added the option, at: https://github.com/jrosdahl/ccache/pull/74 >> 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"... :) Actually it should work out-of-the-box now, including the coloring. It's also part of the test scope now, on both OS X and Linux (ELF). Hopefully that means it'll continue to work, thanks to Travis CI. I meant in the ccache manual, but who reads those things anyway :-) >> 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! :) And you now (soon) have a "keep_comments_cpp" config to complement it! Now, wonder if ccache actually compiles with -Weverything enabled ? Nope - that seems to take a lot of effort. Only 187 errors remaining. /Anders _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
