T
twostars
ci: clang-tidy tweaks (#767)
* In our fork of cpp-linter / cpp-linter-action, we add --clang-tidy-extensions (script) / clang-tidy-extensions (action setting).
This is effectively used for clang-tidy to include all changed files for analysis (i.e. inclusive of headers), while still only directly processing the main source files that were changed.
The big caveat here is that for this to actually report headers, a source file that includes it at some point must also be changed.
* For this to behave, the compile config must all exist - as it was still generating module maps (even though we don't use modules, and we have the global off for this already), these particular files don't exist until build time. Explicitly disabling scans at the target level fixes this.
* Ensure libjpeg-turbo is pre-built in the workflow. This is handled as an ExternalProject in CMake, which ideally we'd handle with a superbuild. For now at least, we can solely build this specific target as we need it to be fetched for its includes to be accessible.
* Fix includes for JpegFile.h and IconItemSkill.h (the 2 known cases without going over the entire codebase again).
* Disable cppcoreguidelines-use-enum-class - this is very common throughout the codebase.
Github Commit Görüntüle...
See Commints...
..
* In our fork of cpp-linter / cpp-linter-action, we add --clang-tidy-extensions (script) / clang-tidy-extensions (action setting).
This is effectively used for clang-tidy to include all changed files for analysis (i.e. inclusive of headers), while still only directly processing the main source files that were changed.
The big caveat here is that for this to actually report headers, a source file that includes it at some point must also be changed.
* For this to behave, the compile config must all exist - as it was still generating module maps (even though we don't use modules, and we have the global off for this already), these particular files don't exist until build time. Explicitly disabling scans at the target level fixes this.
* Ensure libjpeg-turbo is pre-built in the workflow. This is handled as an ExternalProject in CMake, which ideally we'd handle with a superbuild. For now at least, we can solely build this specific target as we need it to be fetched for its includes to be accessible.
* Fix includes for JpegFile.h and IconItemSkill.h (the 2 known cases without going over the entire codebase again).
* Disable cppcoreguidelines-use-enum-class - this is very common throughout the codebase.
Github Commit Görüntüle...
See Commints...
..