(Note: this project has been modified from the original ModernCppStarter so that it is more vscode-friendly.)
Setting up a new C++ project usually requires a significant amount of preparation and boilerplate code, even more so for modern C++ projects with tests, executables and continuous integration. This template is the result of learnings from many previous projects and should help reduce the work required to setup up a modern C++ project.
- Modern CMake practices
- Suited for single header libraries and projects of any scale
- Clean separation of library and executable code
- Integrated test suite
- Continuous integration via GitHub Actions
- Code coverage via codecov
- Code formatting enforced by clang-format and cmake-format via Format.cmake
- Reproducible dependency management via CPM.cmake
- Installable target with automatic versioning information and header generation via PackageProject.cmake
- Automatic documentation and deployment with Doxygen and GitHub Pages
- Support for sanitizer tools, and more
- Use this repo as a template.
- Replace all occurrences of "LmiSolver" in the relevant CMakeLists.txt with the name of your project
- Capitalization matters here:
LmiSolver
means the name of the project, whilelmisolver
is used in file names. - Remember to rename the
include/lmisolver
directory to use your project's lowercase name and update all relevant#include
s accordingly.
- Capitalization matters here:
- Replace the source files with your own
- For header-only libraries: see the comments in CMakeLists.txt
- Add your project's codecov token to your project's github secrets under
CODECOV_TOKEN
- Happy coding!
Eventually, you can remove any unused files, such as the standalone directory or irrelevant github workflows for your project. Feel free to replace the License with one suited for your project.
To cleanly separate the library and subproject code, the outer CMakeList.txt
only defines the library itself while the tests and other subprojects are self-contained in their own directories.
During development it is usually convenient to build all subprojects at once.
Use the following command to build and run the executable target.
cmake -S. -B build
cmake --build build
./build/standalone/LmiSolver --help
Use the following commands from the project's root directory to run the test suite.
cmake -S. -B build
cmake --build build
cd build/test
CTEST_OUTPUT_ON_FAILURE=1 ctest
# or maybe simply call the executable:
./build/test/LmiSolverTests
To collect code coverage information, run CMake with the -DENABLE_TEST_COVERAGE=1
option.
Use the following commands from the project's root directory to check and fix C++ and CMake source style. This requires clang-format, cmake-format and pyyaml to be installed on the current system.
cmake -S. -B build
# view changes
cmake --build build --target format
# apply changes
cmake --build build --target fix-format
See Format.cmake for details.
The documentation is automatically built and published whenever a GitHub Release is created. To manually build documentation, call the following command.
cmake -S. -B build
cmake --build build --target GenerateDocs
# view the docs
open build/documentation/doxygen/html/index.html
To build the documentation locally, you will need Doxygen, jinja2 and Pygments on installed your system.
The test and standalone subprojects include the tools.cmake file which is used to import additional tools on-demand through CMake configuration arguments. The following are currently supported.
Sanitizers can be enabled by configuring CMake with -DUSE_SANITIZER=<Address | Memory | MemoryWithOrigins | Undefined | Thread | Leak | 'Address;Undefined'>
.
Static Analyzers can be enabled by setting -DUSE_STATIC_ANALYZER=<clang-tidy | iwyu | cppcheck>
, or a combination of those in quotation marks, separated by semicolons.
By default, analyzers will automatically find configuration files such as .clang-format
.
Additional arguments can be passed to the analyzers by setting the CLANG_TIDY_ARGS
, IWYU_ARGS
or CPPCHECK_ARGS
variables.
Ccache can be enabled by configuring with -DUSE_CCACHE=<ON | OFF>
.
Can I use this for header-only libraries?
Yes, however you will need to change the library type to an INTERFACE
library as documented in the CMakeLists.txt.
See here for an example header-only library based on the template.
I don't need a standalone target / documentation. How can I get rid of it?
Simply remove the standalone / documentation directory and according github workflow file.
I see you are using
GLOB
to add source files in CMakeLists.txt. Isn't that evil?
Glob is considered bad because any changes to the source file structure might not be automatically caught by CMake's builders and you will need to manually invoke CMake on changes.
I personally prefer the GLOB
solution for its simplicity, but feel free to change it to explicitly listing sources.
I want create additional targets that depend on my library. Should I modify the main CMakeLists to include them?
Avoid including derived projects from the libraries CMakeLists (even though it is a common sight in the C++ world), as this effectively inverts the dependency tree and makes the build system hard to reason about. Instead, create a new directory or project with a CMakeLists that adds the library as a dependency (e.g. like the standalone directory). Depending type it might make sense move these components into a separate repositories and reference a specific commit or version of the library. This has the advantage that individual libraries and components can be improved and updated independently.
You recommend to add external dependencies using CPM.cmake. Will this force users of my library to use CPM.cmake as well?
CPM.cmake should be invisible to library users as it's a self-contained CMake Script.
If problems do arise, users can always opt-out by defining the CMake or env variable CPM_USE_LOCAL_PACKAGES
, which will override all calls to CPMAddPackage
with the according find_package
call.
This should also enable users to use the project with their favorite external C++ dependency manager, such as vcpkg or Conan.
Can I configure and build my project offline?
No internet connection is required for building the project, however when using CPM missing dependencies are downloaded at configure time.
To avoid redundant downloads, it's highly recommended to set a CPM.cmake cache directory, e.g.: export CPM_SOURCE_CACHE=$HOME/.cache/CPM
.
This will enable shallow clones and allow offline configurations dependencies are already available in the cache.
Can I use CPack to create a package installer for my project?
As there are a lot of possible options and configurations, this is not (yet) in the scope of this template. See the CPack documentation for more information on setting up CPack installers.
This is too much, I just want to play with C++ code and test some libraries.
Perhaps the MiniCppStarter is something for you!
- ModernCppStarter & PVS-Studio Static Code Analyzer: Official instructions on how to use the ModernCppStarter with the PVS-Studio Static Code Analyzer.
- lefticus/cpp_starter_project: A popular C++ starter project, created in 2017.
- filipdutescu/modern-cpp-template: A recent starter using a more traditional approach for CMake structure and dependency management.
- vector-of-bool/pitchfork: Pitchfork is a Set of C++ Project Conventions.