【ceph】cmake管理Ceph编译+Ceph工程目录+cmake 实战学习
前言
@bandaoyu,本文随时更新，本文链接:https://blog.csdn.net/bandaoyu/article/details/114739976
CMake是什么，为什么要用CMake：https://blog.csdn.net/bandaoyu/article/details/89031672
ceph cmake工程涉及到的其他知识：《【cmake】CMakeList添加库|添加头文件|添加路径|add_executable、add_library、target_link_libraries|添加编译选项|宏开关》：https://blog.csdn.net/bandaoyu/article/details/115165199
这里有篇很简单的cmake入门博客：
如何编写CMakeList.txt https://www.cnblogs.com/cv-pr/p/6206921.html
CMakeList的HelloWorld ：https://www.cnblogs.com/zhoug2020/p/5904206.html
详尽的Makefile规则教程：https://blog.csdn.net/liang13664759/article/details/1771246
CMake Cookbook：https://www.bookstack.cn/read/CMake-Cookbook/content-preface-preface-chinese.md
Ceph cmake 工程
ceph的编译优化等级、运行时加载库的路径经过cmake生成文件后在link.txt中能看到。（记载库https://blog.csdn.net/bandaoyu/article/details/113181179）
cmake生成的目录
跨平台的编译管理工具。主要作用其实就是根据规则自动生成Makefile，然后使用make命令进行编译链接。
使用cmake需要如下步骤：
1. 编写CMakeList.txt文件
2. 生成Makefile，mkdir build && cd build && cmake ../CMakeList.txt。因为cmake生成的目录文件很多，一般情况下都会创建一个build目录进行放置。
3. 执行make 命令进行项目编译链接。
cmake生成的目录结果大致如下所示：
├── build
│ ├── CMakeCache.txt
│ ├── CMakeFiles
│ │ ├── 3.2.2
│ │ │ ├── CMakeCCompiler.cmake
│ │ │ ├── CMakeCXXCompiler.cmake
│ │ │ ├── CMakeDetermineCompilerABI_C.bin
│ │ │ ├── CMakeDetermineCompilerABI_CXX.bin
│ │ │ ├── CMakeSystem.cmake
│ │ │ ├── CompilerIdC
│ │ │ │ ├── a.out
│ │ │ │ └── CMakeCCompilerId.c
│ │ │ └── CompilerIdCXX
│ │ │ ├── a.out
│ │ │ └── CMakeCXXCompilerId.cpp
│ │ ├── cmake.check_cache
│ │ ├── CMakeDirectoryInformation.cmake
│ │ ├── CMakeOutput.log
│ │ ├── CMakeTmp
│ │ ├── feature_tests.bin
│ │ ├── feature_tests.c
│ │ ├── feature_tests.cxx
│ │ ├── Makefile2
│ │ ├── Makefile.cmake
│ │ ├── progress.marks
│ │ ├── TargetDirectories.txt
│ │ └── test_sqrt.dir
│ │ ├── build.make
│ │ ├── C.includecache
│ │ ├── cmake_clean.cmake
│ │ ├── DependInfo.cmake
│ │ ├── depend.internal
│ │ ├── depend.make
│ │ ├── flags.make
│ │ ├── link.txt
│ │ ├── progress.make
│ │ └── src
│ │ ├── b.c.o
│ │ └── main.c.o
│ ├── cmake_install.cmake
│ ├── Makefile
│ └── test_sqrt
├── CMakeLists.txt
├── include
│ └── b.h
└── src
├── b.c
└── main.c
cmake工程添加新模块（CMakeLists.txt）
ceph CMakeList.txt的结构，如下所示。在工程根目录下有一个总的CMakeList.txt文件，然后使用add_subdirectory语句包含指定文件夹层层递进，从而找到所有的CMakeList的配置。因此，我们在更改ceph源码时，只需要修改该模块下的CMakeList.txt即可。
├── ceph-root
│ ├── build
│ │ ├── ...
│ ├── CMakeLists.txt
│ ├── src
│ │ ├── CMakeLists.txt
│ │ ├── tools
│ │ │ ├── CMakeLists.txt
│ │ ├── osd
│ │ │ ├── CMakeLists.txt
│ │ ├── mon
│ │ │ ├── CMakeLists.txt
│ │ │...
比如，我们想增加一个命令行工具，在 src/tools/ 目录下，新建了一个目录，嗯，叫demo，其程序如下：
#include <boost/program_options.hpp>
#include <iostream>
using namespace std;
namespace po = boost::program_options;
int main(int args, char** argv){
try {
po::options_description generic("Generic Options: ");
generic.add_options()
("help", "help message")
("version,v", "print procedure version");
int opt = 5;
po::options_description ha("haha Options: ");
ha.add_options()
("opt", po::value<int>(&opt)->default_value(10), "optimize value");
po::options_description cmdline_options;
cmdline_options.add(generic).add(ha);
po::variables_map vm;
po::store(po::parse_command_line(args, argv, cmdline_options), vm);
po::notify(vm);
if (vm.count("help")){
cout << cmdline_options << endl;
return 1;
}
cout << "vm opt = " << vm["opt"].as<int>() << endl;
cout << "no opt = " << opt << endl;
}
catch(exception& e) {
}
catch(...) {
}
cout << "haha!" << endl;
return 0;
然后再demo/ 目录下，新建一个CMakeList.txt文件，只需要在文件上写上这么几句话：
set(demo test.cc)
add_executable(demo ${demo})
target_link_libraries(demo global
${BLKID_LIBRARIES} ${CMAKE_DL_LIBS})然后在上层目录的CMakeList.txt中标识demo这个文件。
...
add_subdirectory(demo)
...
然后，返回root/build目录，执行cmake ..，会重新生成一个Makefile，然后执行make demo，就能够找到 build/bin/demo 这个可执行文件，执行就会输出：
@ ./bin/demo --help
Generic Options: :
--help help message
-v [ --version ] print procedure version
haha Options: :
--opt arg (=10) optimize value
按照这个例子，可以引用librados、librbd等库或者函数，然后就可以依样画葫芦，编译出自己的tool了。
原文链接：https://blog.csdn.net/hedongho/article/details/79993098
添加动态库依赖
vi ceph-L/src/osd/CMakeList.txt
target_link_libraries(osd so_libname)
osd:可执行程序名
so_libname：共享库名
表示生成osd 依赖动态库so_libname.so添加库，对应的函数叫LINK_LIBRARIES，把所有的库加进去即可
cmake_minimum_required(VERSION 3.4)
project (Hello)
include_directories("D:/OSGEARTH/include")
LINK_DIRECTORIES("D:/OSGEARTH/lib")
LINK_LIBRARIES(osg osgDB osgViewer)
add_executable(HelloOSG HelloOSG.cpp)cmake导入外部链接库
外部lib
add_library(baz STATIC IMPORTED)
set_target_properties(baz PROPERTIES
IMPORTED_LOCATION_RELEASE ${CMAKE_CURRENT_SOURCE_DIR}/libbaz.a
IMPORTED_LOCATION_DEBUG ${CMAKE_CURRENT_SOURCE_DIR}/libbazd.a)
CMAKE_CURRENT_SOURCE_DIR 这个变量是系统自定义的，表示CMakeLists.txt文件的绝对路径
注意CMakeLists.txt文件的路径，我的这个文件是放在app/src/main 下。
链接：https://www.jianshu.com/p/958a469dabb0
add_library(bar STATIC IMPORTED)
set_target_properties(bar PROPERTIES
IMPORTED_LOCATION_RELEASE ${CMAKE_CURRENT_SOURCE_DIR}/libbar.a
IMPORTED_LOCATION_DEBUG ${CMAKE_CURRENT_SOURCE_DIR}/libbard.a
IMPORTED_LINK_INTERFACE_LIBRARIES baz) # <-- dependency is here
注意动态库和静态库稍有区别：
add_library(bar SHARED IMPORTED)
set_property(TARGET bar PROPERTY IMPORTED_LOCATION c:/path/to/bar.dll)
set_property(TARGET bar PROPERTY IMPORTED_IMPLIB c:/path/to/bar.lib)
add_executable(myexe src1.c src2.c)
target_link_libraries(myexe bar)
内部lib直接写target name就OK，但是必须在同一个proj下
还有一种方式
TARGET_LINK_LIBRARIES(skiaSampleCode
debug skiaCored.lib
optimized skiaCore.lib)
PROJECT_SOURCE_DIR CMAKE_CURRENT_SOURCE_DIR CMAKE_SOURCE_DIR 注意这三者的区别
*.cmake文件
通常我们会复用一些cmake指令(比如将某些指令封装为函数)，将其写到某一个.cmake文件中，然后在我们的CMakeLists.txt使用include命令把.cmake文件包含进来使用里面的函数等。
本例子目录结构：
.
├── build
├── cmake
│ └── test.cmake
└── CMakeLists.txt
test.cmake文件内容增加一个打印字符串的函数：
function(print_string str)
message("str=${str}")
endfunction(print_string)
在CMakeLists.txt中进行include然后调用函数。
包含方式有两种：
1. 直接包含路径及.cmake文件名
2. 先设置CMAKE_MODULE_PATH变量，再包含文件(**不要带.cmake文件扩展名，带了会提示找不到**)
cmake_minimum_required(VERSION 3.5)
project(cmake_test)
#方式一:直接包含路径及.cmake文件
include(${CMAKE_CURRENT_SOURCE_DIR}/cmake/test.cmake)
#方式二:先设置CMAKE_MODULE_PATH变量，这个变量是定义.cmake文件的搜索目录的
# set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake/)
# include(test) ##不要写成test.cmake
print_string("cmake test")# compiler is gnu
if (CMAKE_COMPILER_IS_GNUCC OR CMAKE_COMPILER_IS_GNUCXX)
# C/C++ standard 11
set (CMAKE_C_FLAGS "-std=gnu11 ${CMAKE_C_FLAGS}")
set (CMAKE_CXX_FLAGS "-std=gnu++11 ${CMAKE_CXX_FLAGS}")
# C/C++ build debug
set (CMAKE_C_FLAGS_DEBUG "$ENV{CFLAGS} -O0 -g -ggdb")
set (CMAKE_CXX_FLAGS_DEBUG "$ENV{CXXFLAGS} -O0 -g -ggdb")
# C/C++ build release
set (CMAKE_C_FLAGS_RELEASE "$ENV{CFLAGS} -O3")
set (CMAKE_CXX_FLAGS_RELEASE "$ENV{CXXFLAGS} -O3")
# C/C++ compile options
add_compile_options (
-Wall
-Wextra
-pedantic
-Wimplicit-fallthrough
-Wsequence-point
-Wswitch-default
-Wswitch-enum
-Wtautological-compare
-Wfloat-equal
-Wpointer-arith
-Wpointer-compare
-Wcast-align
-Wcast-qual
-Wwrite-strings
-Wdangling-else
-Wconversion
)
else () #(CMAKE_COMPILER_IS_GNUCC OR CMAKE_COMPILER_IS_GNUCXX)
# C/C++ standard
set (CMAKE_CXX_STANDARD 11)
set (CMAKE_C_STANDARD 11)
endif (CMAKE_COMPILER_IS_GNUCC OR CMAKE_COMPILER_IS_GNUCXX)cmake生成编译DEBUG调试的工程
cmake编译选项 ：https://www.cnblogs.com/hustdc/p/10226508.html
SET(CMAKE_BUILE_TYPE DEBUG) #编译出来的程序可用于调试
CMAKE_BUILD_TYPE 这种东西往往是在CMakeList.txt 中定义的, 这个是你要编译的类型, 一般的选择有debug,release
IF( NOT CMAKE_BUILD_TYPE )
SET( CMAKE_BUILD_TYPE Release ... FORCE )
ENDIF()如果是编译release版本的话，
mkdir Release
cd Release
cmake -DCMAKE_BUILD_TYPE=Release ..
make
如果是编译debug版本的话，
mkdir Debug
cd Debug
cmake -DCMAKE_BUILD_TYPE=Debug ..
make
这里CMAKE_C_FLAGS_DEBUG默认只是有一个“-g”，所以，可以在此基础上添加优化选项
set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0")
set(CMAKE_C_FLAGS_Release "${CMAKE_C_FLAGS_Release} -O3")
给GCC添加参数项|关闭指定警告|设定优化等级
可以给全局加，也可以只给生成某个target加
给全局加：
在CMakeLists.txt文件中加上：
方法一：如果CMakeList.txt 设置了CMAKE_C_FLAGS这些宏并
#给CMAKE_C_FLAGS添加-Wno-unused-function 即 CMAKE_C_FLAGS="${CMAKE_C_FLAGS} -Wno-unused-function“
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-unused-function")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unused-function")
CMAKE_C_FLAGS是给gcc（C语言）设置编译参数，CMAKE_CXX_FLAGS是给g++（C++）设置编译参数
方法二：
add_definitions(-Wall) 给GCC 添加-Wall
关闭告警见：
https://blog.csdn.net/bandaoyu/article/details/115419255
给某个target加
在CMakeLists.txt中添加add_definitions(-w)
应用于单个target
if（CMAKE_COMPILER_IS_GNUCC）
target_compile_options（main PRIVATE"-Wall"）
endif（）
if（MSVC）
target_compile_options（main PRIVATE"/ W4"）
endif（）
应用于所有target
if（CMAKE_COMPILER_IS_GNUCC）
set（CMAKE_CXX_FLAGS"$ {CMAKE_CXX_FLAGS} -Wall"）
endif（）
if（MSVC）
set（CMAKE_CXX_FLAGS"$ {CMAKE_CXX_FLAGS} / W4"）
endif（）
注意：为GCC或/ WX添加-Werror以便MSVC将所有警告视为错误。这会将所有警告视为错误。这对于新项目来说可以方便地执行严格的警告。
另外， -Wall 并不意味着"所有错误";从历史意义上讲，它意味着"每个人都可以达成一致的所有错误""。从 -Wall -Wextra 开始，然后仔细阅读您的版本的GCC手册，并找到 else 编译器可以为您提供关于警告的信息。
————————————————
原文链接：https://blog.csdn.net/bandaoyu/article/details/115165199
设置优化等级：
如果有CMAKE_C_FLAGS_DEBUG，这里CMAKE_C_FLAGS_DEBUG默认只是有一个“-g”，所以，可以在此基础上添加优化选项
set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -O0")
set(CMAKE_C_FLAGS_Release "${CMAKE_C_FLAGS_Release} -O3")
如果没有CMAKE_C_FLAGS_DEBUG，就用前面提的方法。
可以通过下面的命令查找工程中设置优化项的地方：
grep -nR "\-O" ./ --include=*.txt
过滤掉含有 build、boost、erasure-code、doc、link.txt字样的结果
grep -nR "\-O" ./ --include=*.txt|grep -vE "build|src_bak|boost|erasure-code|doc|link.txt"
优化项|优化等级说明
更多和详细解释：https://blog.csdn.net/bandaoyu/article/details/123700034
-O0禁止编译器进行优化。默认为此项。
-O1尝试优化编译时间和可执行文件大小。
-O2更多的优化，会尝试几乎全部的优化功能，但不会进行“空间换时间”的优化方法。
-O3在 -O2 的基础上再打开一些优化选项：-finline-functions， -funswitch-loops 和 -fgcse-after-reload 。
-Os对生成文件大小进行优化。它会打开 -O2 开的除了会那些增加文件大小的全部选项。
原文链接：https://blog.csdn.net/bandaoyu/article/details/115419255
使用CMake时忽略外部模块中的警告
在使用带有add_subdirectory的外部模块,它展示了一些我们不喜欢的警告：
（还未研究）http://www.voidcn.com/article/p-uzaxjsld-bto.html
设置生成目标
add_executable(ceph-dencoder ${dencoder_srcs}) ，设置要用${dencoder_srcs}生成 可执行文件 ceph-dencoder
target_link_libraries(ceph-dencoder ，设置要用生成 ceph-dencoder 要连接的库
global
os
osd
mds
mon
journal
${DENCODER_EXTRALIBS}
cls_lock_client
cls_refcount_client
cls_log_client
cls_statelog_client
cls_version_client
cls_replica_log_client
cls_user_client
cls_journal_client
cls_timeindex_client
${EXTRALIBS}
${CMAKE_DL_LIBS}
)
Ceph 源代码目录结构
1 简介
该代码架构基于版本10.0.5整理，先整理根目录里的代码，再整理出src目录的架构。
2 代码架构
2.1 Ceph源码根目录
Ceph的根目录下包含了一些文件夹和若干编译、代码格式相关的文件。
[admin]：架设Document服务器，包括依赖内容并介绍修改doc的流程。
[bin]：目前只包含一个在当前目录针对所有内容生产tar包的脚本
[cmake]：Ceph对cmake的支持。CMake 是一个跨平台的自动化安装编译系统,它使用一个名为 CMakeLists.txt 的文件来描述构建过程,可以产生标准的构建文件,如 Unix 的 Makefile 或Windows Visual C++ 的 projects/workspaces 。文件 CMakeLists.txt 需要手工编写,也可以通过编写脚本进行半自动的生成。CMake 提供了比 autoconfig 更简洁的语法。
[debian]：用于制作debian（Ubuntu）安装包的相关脚本和文件。
[doc]：Ceph文档系统的源码，Ceph的文档和manpages都使用rst格式，该目录的内容将通过doc web服务器导出，最终效果如：http://docs.ceph.com/docs/master/
[etc]：Ceph的etc文件
[examples]：一些Ceph开发、命令使用、trace使用的例子。
[qa]：各个模块的功能测试（测试脚本和测试代码）
[src]：Ceph各个模块的源码目录
[systemd]：Ceph对于systemd的支持目录
[udev]：Ceph的udev规则
AUTHORS：记录了Ceph的Maintainer、CTL（Component Technical Leads）以及Contributors信息。
do_autogen.sh/autogen.sh/configure.ac：生成configure文件
run-cmake-check.sh ：使用cmake编译ceph，适用于首次自动化编译，自动安装依赖包，需要运行用户有安装包的权限。
run-make-check.sh ：使用make编译ceph，适用于首次自动化编译，自动安装依赖包，需要运行用户有安装包的权限。
Makefile.am：用于生成Makefile文件
ceph.spec.in：Ceph打包的spec文件
CMakeLists.txt：CMake工具使用的描述文件
CodingStyle：Ceph的代码编写规范
2.2 Ceph src目录内容
src目录包含了Ceph主要模块的源码，整体上可以分为三层，如下图所示：
1）Base
基础层包含了与业务无关的各类模块，例如对数值类型的定义、线程池、序列化等。
[include]：头文件，包含各种基本类型的定义，简单通用功能等。
[common]：共有模块，包含各类共有机制的实现，例如线程池、管理端口、节流阀等。
[log]：日志模块，主要负责记录本地log信息（默认/var/log/ceph/目录）
[global]：全局模块，主要是声明和初始化各类全局变量（全局上下文）、构建驻留进程、信号处理等。
[tracing]：Ceph tracing模块，目前支持使用lttng，可以在该目录下定义lttng的tracepoint。
2）Component
组件层是为实现各项业务提供的功能组件，例如消息通讯、认证授权、数据分布算法等。
[crush]：Crush模块，Ceph的数据分布算法 。其中CrushCompiler.cc主要负责对crushtool命令传入的crushmap.txt进行compile和parse(parse_tunable、parse_device、parse_bucket_type、parse_bucket、parse_rule），拿parse rule来说，解析后会通过CrushWrapper.h中的add_rule调用builder.cc的crush_add_rule实现rule的添加。总的来说crush.h 中定义了crush_map的结构和四种bucket类型，builder.c文件定义了crushmap中关于rule、bucket的增删改查操作。mapper定义了crushmap中的step、choose操作，而hash.c中定义了crush中使用的rjenkins算法。
[os]：对象存储（Object Store）模块，用于实现本地的对象存储功能，目前包括：bluestore、filestore、kstore、memstore；其中*store的基类为ObjectStore，定义在ObjectStore.h中。常用的是FileStore，定义在filestore目录，而Ceph为了解决性能问题，目前正在全力开发bluestore。这里先主要关注一下FileStore，在FileStore.h中主要定义了FileStore和FileStoreBackend两个类，其中FileStore中定义了Op的操作模型（OpWQ、OpSequencer）和transaction的操作模型，它继承自JournalingObjectStore类。而FileStoreBackend类定义了FileStore获取后端具体文件系统的一些操作。
[auth]：授权模块，实现了三方认知机制。
[msg]：消息通讯模块， OSD使用msg模块进行网络通讯，包括监听客户端的IO，与其它osd收发消息，以及与mon进行通讯等。该目录下包括用于定义通讯功能的抽象类Messenger以及目前的实现SimpleMessager、AsyncMessenger、XIO。
[messages]：消息模块，定义了Ceph各节点之间消息通讯中用到的消息类型。
[osdc]：OSD客户端（OSD Client），主要包括Objecter、ObjectCacher、Striper、Filer和Journaler。Objecter主要是将request封装成对应的Ops、计算出request需要发送的OSD并且以message的方式将Op发送出去。ObjectCacher是client端的Cache层。Stripper是将一个块设备映射成object，而Filer是把file的range映射成object。Journaler主要是用于MDS的
[kv]：定义了keyvaluestore的后端存储实现。
[cls]：针对第三方插件的支持。
3）SubSystem
子系统层即Ceph中各个功能节点，包括:
[mon]：Monitor作为Ceph集群状态管理者管理MonMap、PGMap和OSDMap，其主要由各种Monitor组件组成，并使用Paxos协议实现Mon之间数据同步来保证数据一致性，通过quorum协议来保证Mon之间的高可用。
AuthMonitor、LogMonitor、MDSMonitor、MonmapMonitor、OSDMonitor、PGMonitor、HealthMonitor
MonMap、PGMap、OSDMap
MonClient、MonCommands
Paxos、PaxosService、QuorumService
DataHealthService、HealthService、ConfigKeyService
MonitorDBStore
[osd]：定义了后端OSD、PG相关的类和处理逻辑。 在OSD模块中，最核心、也是实际处理IO请求和故障恢复的模块类是PG。 PG是一个对象的集合，包含对象名称的哈希值与PG的ID相符的所有对象。而在Ceph的软件设计中，PG是osd中处理IO的类，即属于某一个PG的对象的请求，全部由该对象对应的PG类的实例进行处理。 相对于PG，OSD实际扮演了一个服务者的角色，即为PG提供了以下服务：1）通过调用os模块提供本地存储服务；2）通过调用msg模块提供消息通讯服务；3）通过提供线程池提供计算服务。 可以将OSD理解为PG的运行环境。PG“生活”在某一个OSD中，也可能由于系统的变化，而迁移到另一个OSD中，这一过程实际也就是数据迁移的过程。
学习osd模块可以从一下类开始，稍后会整理出各类的作用以及相互之间的关系。
OSD、OSDService、OSDMap
PG、PGBackend、ReplicatedPG、ReplicatedBackend、PGLog
ECBackend、ECTransaction
HitSet
[mds]：MDS定义了维护了CephFS中的元数据，包括文件系统的树形结构、文件的属性、访问控制信息等，这些数据都是存在MDS节点的内存中，而真正的数据是存储在Rados里的。
MDSDaemon、MDSRank、MDSMap、Beacon、MDCache、MDBalancer
CDir、CDentry、CInode
MDSTable、InoTable
[client]：Client主要定义了CephFS client端的代码。
[rbd]：实现包括两部分：krbd（kernel版的rbd，源码在drivers/block/rbd.c）和librbd。
[rgw]：实现了rgw的功能，rgw的主要作用是协议转换，即把HTTP协议的请求转化为RGW Object再转换为Rados Object，交由Rados处理。
[tools]：Ceph中的各种工具的实现：cephfs、rados、rbd、rbd-nbd、ceph-authtool、ceph-conf、ceph-kvstore-tool、ceph-monstore-tool、ceph-objectstore-tool、crushtool、monmaptool、osdmaptool
[librados]：librados实现了rados层的接口，其中几个重要的数据结构有Rados、RadosClient、IoCtx、IoCtxImpl。IoCtx（include/rados/librados.hpp）是Rados I/O的一个上下文，其定义了大部分的I/O接口如read、write等；
原文链接：
https://blog.csdn.net/scaleqiao/article/details/51165575
Ceph源码目录架构：http://www.360doc.com/content/17/0814/10/46248428_679061773.shtml
作者bandaoyu@uestc，本文连接：https://blog.csdn.net/bandaoyu/article/details/114739976
cmake清除缓存的操作（类似 make clean）
想要通过make clean类似的操作删除CMake生成的各种文件。
发现cmake没有类似的操作，需要手动浏览目录，删除像cmake_install.cmake和CMakeCache.txt CMakeFiles文件，以及CMakeFiles文件夹。
是否有像cmake clean这样的命令来自动删除所有这些文件？
通过查看cmake命令的help发现可以通过创建一个额外的文件夹的方式实现：
cmake -S . -B build
之后每次操作直接删除掉build文件就可以了。
原文链接：https://blog.csdn.net/daijingxin/article/details/111826612
