Re: Speeding up builds with clang-tidy, clang-analyzer and iwyu
Joel Rosdahl via ccache <[email protected]> Tue, 18 Aug 2020 21:48:41 +0200
| Newsgroups | gmane.comp.compilers.ccache |
|---|---|
| Message-ID | <CAK8D=piZ0DEDV_1uO9ppVNH_8JZOnx=dT02g0rCHhgMOui4Qww@mail.gmail.com> |
On Mon, 17 Aug 2020 at 15:34, Christian Ledergerber <[email protected]> wrote: > [...] The point is: I think this is not a coner-case, but people use this > configuration abundantly. I just wanted to stress the point that tools need to handle all configurations correctly, regardless of whether they are popular or not. > > 3. The method is also brittle since the clang-tidy step will be skipped if > > the source is built (and therefore cached) by a normal non-clang-tidy > > build. > > This I do not understand. Would this not be caught by the extra files to > cache? So: if the ccache caches also the configuration of clang-tidy then > there cannot be a cache hit due to binaries built without using clang-tidy? The case I was thinking about is this: if a user sets CCACHE_EXTRAFILES (or extra_files_to_hash in the configuration) to the .clang-tidy configuration file and builds without running clang-tidy then user will have circumvented the logic by placing a result in the cache without being stopped by clang-tidy. This likely won't happen in practice; I'm just trying to find out if there are edge cases where the assumptions can break down. > Thanks for this comment! I feel like for easy integration into cmake (and > other tools) one would need another command line flag which allows adding > extra files to cache. E.g. --add-extra-files=file1;file2;file3. That would be possible. The main thing I think feels problematic with your idea is that it will require tight coupling between CMake and ccache, something I wouldn't like to have if I were a CMake maintainer. But since I'm not, I'll leave that discussion to you and them. -- Joel