A collection of reusable CMake modules and find scripts for standardizing C/C++ project builds, testing, and packaging.
Eyescale/CMake is a collection of reusable CMake modules that provide standardized recipes and utilities for building, testing, and packaging C/C++ projects. It simplifies CMake configuration by offering common functions for creating libraries and applications, managing dependencies, and integrating tools for code analysis and documentation.
C/C++ developers and project maintainers who use CMake as their build system and want to standardize their project structure, automate testing, and simplify dependency management.
It reduces CMake boilerplate, enforces consistent build practices across projects, and integrates essential tools like static analyzers, coverage reporting, and documentation generators directly into the build process.
Common CMake modules
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Provides common_library() and common_application() functions that simplify creating libraries and executables with consistent configurations, reducing CMake boilerplate as highlighted in the README.
Automatically sets up unit tests with CTest and adds targets for code coverage (coverage) and static analysis (cppcheck, clangcheck), enhancing code quality without manual configuration.
The common_find_package() function improves on CMake's find_package by generating feature-checking files (defines.h, options.cmake) for non-CMake dependencies, streamlining project setup.
Includes modules like CommonPackageConfig and CommonCPack for generating installable packages and CMake config files, plus a doxygen target for automated API documentation generation.
Features such as InstallDependencies only support Linux distributions (apt-get, yum) and macOS (MacPorts), lacking Windows support and limiting cross-platform usability out of the box.
For subproject management, existing projects must modify CMake scripts to use PROJECT_BINARY_DIR instead of CMAKE_BINARY_DIR, adding complexity and potential integration hurdles.
Enforces specific conventions (e.g., through common_compile_options()) that may not align with all project needs, requiring workarounds if deviations from defaults are necessary.
Requires integration as a git submodule, which can complicate repository management and updates compared to using CMake's built-in modules or package managers like vcpkg.