ModernCppStarter

通常，建立一个新的C++项目需要大量的准备工作和样板代码，对于具有测试、可执行文件和持续集成的现代C++项目来说，更是如此。这个模板是从许多以前的项目中学习而来的结果，应该有助于减少建立一个现代C++项目所需的工作。

特性

现代CMake实践
适用于单头文件库和任何规模的项目
库代码和可执行代码的清晰分离
集成测试套件
通过GitHub Actions进行持续集成
通过codecov进行代码覆盖率分析
通过Format.cmake使用clang-format和cmake-format强制执行代码格式化
通过CPM.cmake进行可重现的依赖管理
通过PackageProject.cmake实现可安装目标，自动版本信息和头文件生成
使用Doxygen和GitHub Pages自动生成和部署文档
支持sanitizer工具等其他功能

使用方法

根据需求调整模板

使用此仓库作为模板。
在相关的CMakeLists.txt中，将所有出现的"Greeter"替换为你的项目名称
- 这里区分大小写：Greeter指项目名称，而greeter用于文件名。
- 记得将include/greeter目录重命名为你的项目的小写名称，并相应地更新所有相关的#include。
用你自己的源文件替换现有的源文件
对于仅头文件的库：请参阅CMakeLists.txt中的注释
将你的项目的codecov令牌添加到项目的GitHub secrets中，键名为CODECOV_TOKEN
开始愉快的编码吧！

最终，你可以删除任何未使用的文件，如standalone目录或与你的项目无关的GitHub工作流。随意将许可证替换为适合你项目的许可证。

为了清晰地分离库和子项目代码，外部的CMakeList.txt只定义了库本身，而测试和其他子项目则在它们自己的目录中是自包含的。在开发过程中，通常方便一次性构建所有子项目。

构建和运行独立目标

使用以下命令构建和运行可执行目标。

cmake -S standalone -B build/standalone
cmake --build build/standalone
./build/standalone/Greeter --help

构建和运行测试套件

从项目的根目录使用以下命令运行测试套件。

cmake -S test -B build/test
cmake --build build/test
CTEST_OUTPUT_ON_FAILURE=1 cmake --build build/test --target test

# 或者直接调用可执行文件：
./build/test/GreeterTests

要收集代码覆盖率信息，请使用-DENABLE_TEST_COVERAGE=1选项运行CMake。

运行clang-format

从项目的根目录使用以下命令检查和修复C++和CMake源代码样式。这需要在当前系统上安装_clang-format_、cmake-format_和_pyyaml。

cmake -S test -B build/test

# 查看更改
cmake --build build/test --target format

# 应用更改
cmake --build build/test --target fix-format

详情请参阅Format.cmake。这些依赖可以使用pip轻松安装。

pip install clang-format==14.0.6 cmake_format==0.6.11 pyyaml

构建文档

每当创建GitHub Release时，文档会自动构建和发布。要手动构建文档，请调用以下命令。

cmake -S documentation -B build/doc
cmake --build build/doc --target GenerateDocs
# 查看文档
open build/doc/doxygen/html/index.html

要在本地构建文档，你需要在系统上安装Doxygen、jinja2和Pygments。

一次性构建所有内容

该项目还包括一个all目录，允许同时构建所有目标。这在开发过程中很有用，因为它将所有子项目暴露给你的IDE，并避免了库的重复构建。

cmake -S all -B build
cmake --build build

# 运行测试
./build/test/GreeterTests
# 格式化代码
cmake --build build --target fix-format
# 运行独立程序
./build/standalone/Greeter --help
# 构建文档
cmake --build build --target GenerateDocs

其他工具

测试和独立子项目包括tools.cmake文件，用于通过CMake配置参数按需导入其他工具。目前支持以下工具。

Sanitizers

静态分析器

可以通过设置-DUSE_STATIC_ANALYZER=<clang-tidy | iwyu | cppcheck>来启用静态分析器，或者在引号中用分号分隔的组合。默认情况下，分析器会自动查找配置文件，如.clang-format。可以通过设置CLANG_TIDY_ARGS、IWYU_ARGS或CPPCHECK_ARGS变量来向分析器传递额外的参数。

Ccache

可以通过配置-DUSE_CCACHE=<ON | OFF>来启用Ccache。

常见问题

我可以将此用于仅头文件的库吗？

可以，但你需要将库类型更改为INTERFACE库，如CMakeLists.txt中所述。参见这里有一个基于该模板的仅头文件库的例子。

我不需要独立目标/文档。如何去掉它？

只需删除standalone/documentation目录和相应的github工作流文件。

我可以同时构建独立程序和测试吗？/ 如何让我的IDE了解所有子项目？

为了保持模板的模块化，所有从库派生的子项目都被分离到它们自己的CMake模块中。这种方法使第三方项目重用项目的库代码变得非常简单。为了让IDE看到项目的全貌，该模板包含了all目录，它将为所有子项目创建一个单一的构建。使用这个作为主目录可以获得最佳的IDE支持。

我看到你在 CMakeLists.txt 中使用 GLOB 来添加源文件。这不是很不好吗？

GLOB 被认为是不好的做法，因为对源文件结构的任何更改可能不会被 CMake 的构建器自动捕获，你需要在更改时手动调用 CMake。我个人更喜欢 GLOB 解决方案，因为它简单，但你可以随意将其更改为显式列出源文件。

我想创建依赖于我的库的额外目标。我应该修改主 CMakeLists 来包含它们吗？

避免在库的 CMakeLists 中包含派生项目（尽管这在 C++ 世界中很常见），因为这实际上颠倒了依赖树，使构建系统难以理解。相反，创建一个新的目录或项目，其 CMakeLists 将库作为依赖项添加（例如，像 [standalone] 目录那样）。根据类型，将这些组件移到单独的仓库中并引用库的特定提交或版本可能更有意义。这样做的好处是各个库和组件可以独立改进和更新。

你建议使用 CPM.cmake 添加外部依赖。这会强制我的库的用户也使用 CPM.cmake 吗？

[CPM.cmake] 应该对库用户是透明的，因为它是一个独立的 CMake 脚本。如果确实出现问题，用户总是可以通过定义 CMake 或环境变量 [CPM_USE_LOCAL_PACKAGES] 来选择退出，这将用相应的 find_package 调用覆盖所有对 CPMAddPackage 的调用。这也应该使用户能够使用他们喜欢的外部 C++ 依赖管理器，如 vcpkg 或 Conan。