[ccache] Speeding up builds with clang-tidy, clang-analyzer and iwyu

Christian Ledergerber christian.ledergerber at ecorobotix.com
Mon Dec 7 07:15:35 UTC 2020

Hi Steffen,

I was in the same situation as you, porting / cleaning up a legacy code base to use clang-tidy. Except that the legacy code base was only a year old.

I ended up writing the following wrapper to cmake's add_executable and add_library:

    set(oneValueArgs PROJECT_NAME)
    cmake_parse_arguments(ARG "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})

    add_executable(${ARG_PROJECT_NAME} ${ARG_SOURCES})


this allows me to mix "ugly" code with "pretty" code in the same project in a very flexible manner on a module / library basis. Any module for which one of the things has been cleaned up we enable the automatic check and hence never go backwards. This way at least I got clang-format into place and most of the code is now using some form of clang-tidy checking.

Thanks for your idea on the wrapper script. Did you end up trying it? I still plan to attack this problem one day, but the wrapper script sounds a lot easier.
I guess the drawback is that things are not recompiled if you change the clang-tidy configuration. But maybe this can be fixed somehow or we could live with this.


From: ccache <ccache-bounces at lists.samba.org> on behalf of Steffen Dettmer via ccache <ccache at lists.samba.org>
Sent: Friday, December 4, 2020 17:00
To: ccache list
Subject: Re: [ccache] Speeding up builds with clang-tidy, clang-analyzer and iwyu


On Sun, Aug 2, 2020 at 6:55 PM Christian Ledergerber via ccache <
ccache at lists.samba.org> wrote:
> for our builds currently clang-tidy is currently the limiting factor in
> terms of speed.
> There is one utility out there which tries to cache the output of
> clang-tidy, however it seems to be stale:
> https://github.com/ejfitzgerald/clang-tidy-cache
> Yet, I have the impression that my case is much simpler:

Do you have any new regarding caching clang-tidy?

Here we also occasionally discuss things and we found the following
opinions in our teams:
1) clang-tidy shall be in the IDE: it can apply fixes which needs
2) clang-tidy shall be a Jenkins job: When you are using it for a while,
number of warnings reduce a lot and it is not necessary to run it every time
3) clang-tidy shall be ran at every compilation: it is -Wall -Wextra -Wtidy
made correctly

For 3), which seems to be close to your use case, someone proposed in
context of a legacy project to run clang-tidy along with the compiler. The
discussed approach was to have a wrapper script to be used as a compiler,
but the wrapper script also called clang-tidy before it ran the compiler.

In this case, ccache would not call the compiler in case of a cache hit,
which here means it would not call the wrapper script and thus not
clang-tidy, so I think this could help you. Maybe.

(the idea was quickly discarded because there was absolutely no way to fix
the legacy code due to its ancient C++ and we joked about adding a
--museum-mode to clang-tidy :))

ccache mailing list
ccache at lists.samba.org

More information about the ccache mailing list