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 

    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-boun...@lists.samba.org> on behalf of Steffen Dettmer via 
ccache <ccache@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 


On Sun, Aug 2, 2020 at 6:55 PM Christian Ledergerber via ccache <
ccache@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 mailing list

Reply via email to