On Mon, 17 Aug 2020 at 15:34, Christian Ledergerber <christian.lederger...@ecorobotix.com> 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 _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
