MantisBT - Doomseeker
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003816Doomseeker[All Projects] Suggestionpublic2020-06-07 06:192020-06-07 20:54
ReporterWubTheCaptain 
Assigned To 
PrioritylowSeverityfeatureReproducibilityN/A
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version1.3 
Target VersionFixed in Version 
Summary0003816: We don't use clang-tidy and it's not integrated to CMake
DescriptionSo... Integrating clang-tidy into CMake.
Issue 0003591 initially suggested .clang-format. The issue ended up with uncrustify.
I have to admit I never ran uncrustify. Now I learned there's CMAKE_CXX_CLANG_TIDY for CMake, and that seems... more optimal, in a way.
Given that I've been looking for clang-tidy issues manually and reporting issues (12+ I count) from it today (without actually running clang-tidy), it seems like an useful tool. I should ask: Should we integrate clang-tidy with our CMake build process? May turn uncrustify unnecessary, I don't know.
Steps To Reproduce
Additional Information'https://ortogonal.github.io/cmake-clang-tidy/ [^]'
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2020-06-07 06:19WubTheCaptainNew Issue
2020-06-07 20:53Pol MNote Added: 0021390
2020-06-07 20:54Pol MStatusnew => feedback

Notes
(0021390)
Pol M   
2020-06-07 20:53   
Quote

May turn uncrustify unnecessary, I don't know.

Nope :). uncrustify provides us with formatting, which is important in order to simplify a global coding convention, while clang-tidy does a different job, which is to report on suspicious code patterns.

Onto whether it should be integrated into cmake, I'd argue that it is not necessary. You can accually just generate a "compile_commands.json" file and with a script like'https://clang.llvm.org/extra/doxygen/run-clang-tidy_8py_source.html [^]' you can run it through the entirety of our code. No need to touch cmake! :D