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: function(add_executable_with_checks) set(options DISABLE_CLANG_TIDY_READABILITY DISABLE_CLANG_TIDY_MODERNIZE DISABLE_CLANG_TIDY_NAMING_CONVENTION DISABLE_CLANG_TIDY_BUGPRONE DISABLE_CLANG_ANALYZER DISABLE_CLANG_TIDY_CPP_CORE_GUIDELINES DISABLE_COMPILER_ERROR) set(oneValueArgs PROJECT_NAME) set(multiValueArgs SOURCES HEADERS) cmake_parse_arguments(ARG "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN}) ... add_executable(${ARG_PROJECT_NAME} ${ARG_SOURCES}) ... endfunction() 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. Christian ________________________________________ 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 iwyu Hi, 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 interaction 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 :)) Steffen _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache