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

Reply via email to