Skip to content

CMakeLists, Clang Tooling And General Cleanup

Administrator requested to merge clang-tooling into master

This unfortunately rather large MR does the following things:

Introduce a .clang-format

clang-format is much more strict and complete compared to other code formatters because it uses libclang for parsing the code. This .clang-format was generated from the LLVM style with the line length set to 120 being the only change.

There are plugins for pretty much every editor out there. Additionally, clang ships with a git hook so it can be conveniently applied while pushing the source code.

Reformat of the codebase

The code was reformatted using .clang-format. I have kept the .editorconfig because it contains rules for other languages. Ideally, clang-format is added to the CI to ensure consistent formatting in the future.

Introduce a CMakeLists

Although this adds another dependency to building the code, this brings the following improvements over (the existing) Makefile:

  • Out-of-the-box integration in many popular IDEs (e. g. Visual Studio, Qt Creator, KDevelop, CLion) with plugins available for some text editors. This makes code completion and syntax highlighting much more robust as all the include paths and compiler flags are queried from the build system
  • Integration of clang-tidy and cppcheck: When enabled, linters are run on the source code while building it with a regular compiler. include-what-you-use is also supported, but not yet enabled in my script
  • Proper dependency scanning: Should one of the dependencies (SDL2, SDL2-TTF, libcryptsetup) not be available for the target system, it gives a meaningful error message. This is also true for outdated (pre C++14) or broken compilers.
  • Packaging of the application: An install rule is provided. In other CMake projects, developers can simply write find_package(osk-sdl) to find and use osk-sdl as pmos::osk-sdl in their build script. A PkgConfig hasn't been added yet, but is trivial to write. CPack support could also be added in the future.
  • Platform independence: It is possible to build the code with non gcc-style compilers. The build system is also OS-independent now, but this is just a theoretical feature because of libcryptsetup.
  • More compiler flags: LTO is enabled in release builds, debug symbols are only generated in debug mode. More warnings are enabled, documentation and thread safety warnings are enabled if clang is used.
  • Initial testing support: Although no tests have been added yet, by registering them with add_test() they can all be executed at once by calling ctest . in the build directory. This simplifies the CI process.

I haven't removed the Makefile (yet?) to ease the transition. Switching to CMake would also mean a change in the aport.

Add a .clang-tidy

I have enabled the most obvious checks for now, but it still requires some tweaking (for example, enabling identifier naming checking requires more configuration).

Clean the code of all warnings

I enabled -Wall -Wextra -Wpedantic on gcc 8.2, all checks listed in the .clang-tidy, Address and Undefined Sanitizer and cleaned the code of all warnings. Things that were fixed include, but are not limited to, are:

  • Memory leaks in draw_helpers.cpp
  • Undefined behavior due to uninitialized variables
  • Killed using namespace std;
  • Made all narrowing conversions explicit with static_cast or changing the types
  • Removed a whole bunch of unnecessary memory allocations
    • constexpr char[] instead of global std::strings
    • std::move and emplace_back
    • Removal of std::function, replaced with a template parameter
    • range-for
  • General modernization
    • NULL -> nullptr
    • std::list -> std::vector (closes #37 (closed))
    • Don't use delete, use RAII
    • STL algorithms
    • References instead of pointers
    • Use more standard library types (<chrono>)
Edited by Administrator

Merge request reports

Loading