现代 CMake 模块化项目管理指南 彭于斌（ @archibate ） 课件 & 源码： https://github.com/parallel101/course 往期录播： https://space.bilibili.com/263032155 找不到头文 件怎么办呀 CMake Cookbook 小彭老师建议 : ~~-·~·~-·~ -~·-·~·- 第一章：文件 / 项目，如何优雅地、模块化地组织大量源文件 ？ 推荐的目录组织方式 • 目录组织格式： • 项目名 /include/ 项目名 / 模块名 .h • 项目名 /src/ 模块名 .cpp • CMakeLists.txt 中写： • target_include_directories( 项目名 PUBLIC include) • 源码文件中写： • #include < 项目名 / 模块名 .h> 推荐的目录组织方式 • 头文件（项目名 /include/ 项目名 / 模块名 .h ）中写： • #pragma once • namespace 项目名 { • void 函数名 (); • } • 实现文件（项目名 /src/ 模块名 .cpp ）中写： • #include < 项目名 / 模块名 .h> • namespace 项目名 { • void 函数名 ()

另一种方式：先创建目标，稍后再添加源文件 如果有多个源文件呢？ 逐个添加即可 使用变量来存储 建议把头文件也加上，这样在 VS 里可以出现在“ Header Files” 一栏 使用 GLOB 自动查找当前目录下指定扩展名的文件，实现批量添加源文件 启用 CONFIGURE_DEPENDS 选项，当添加新文件时，自动更新变量 如果源码放在子文件夹里怎么办？ 必须把路径名和后缀名的排列组合全部写出来吗？感觉好麻烦 CMAKE_CURRENT_BINARY_DIR 表示当前输出目录的位置，例如 ~/hellocmake/build 。 project ：初始化项目信息，并把当前 CMakeLists.txt 所在位置作为根 目录 和子模块的关系： PROJECT_x_DIR 和 CMAKE_CURRENT_x_DIR 的 区别 PROJECT_SOURCE_DIR 表示最近一次调用 project 的 CMakeLists.txt CMAKE_SOURCE_DIR 表示最为外层 CMakeLists.txt 的源码根目录。 利用 PROJECT_SOURCE_DIR 可以实现从子模块里直接获得项目最外层目录的路径。 不建议用 CMAKE_SOURCE_DIR ，那样会让你的项目无法被人作为子模块使用。 其他相关变量 • PROJECT_SOURCE_DIR ：当前项目源码路径（存放 main.cpp 的地方） • PROJECT_BINARY_DIR

实施负担较重难以推广 面向多云厂商友好，实施迁移成本极低，可扩展性 强，全球多地跨云跨域安全可靠自动化部署 企业基于 CI/CD 工具自建 DevOps 流程平台 围绕 Jenkins 、 Tekton 、 Argo 等 搭建流程串接胶水平台 建设成本高 500-2000 万之间 使用和学习门槛高；随业务发展扩展性差 局限性大，内部推广难度极高，做完后维 护成本高价值难被证明 护成本高价值难被证明 低采购成本、低实施成本， 内置模板库和最佳实践；高扩展性、技术先进性强 ，可灵活广泛接入现有工具链和业务场景 基于代码管理的 DevOps 方 案 Gitee 平台 GitLab 平台 局限性大、全流程安全性低 维护成本高 支持多个服务并行构建部署、产品级发布，可灵活 安全接入多个代码仓及周边工具链 Zadig 与现存 DevOps 方案对比 来自客户的评价： 企 业 合 规 S O P 流 程 ， 灰 度 蓝 绿 部 署 策 略 ， 完 成 生 产 环 境 发 布 最 后 一 公 里 特色模块（一） – 发布管理 多服务编排升级 配置变更 生产观测 数据变更 灰度发布 流程自动化 特色模块（二） – 客户交付 供应商产品生命周期管理 为客户提供生命周期管理 管理不同渠道的版本 可部署到任何环境 简 化 对 客 户 的 本

效利用硬件资源，高可用，高 可靠，故障自愈，低成本运维 HTAP Hybrid Transactional/Analytical Processing ，高性能图计算引 擎，预置 20 余种图计算算法 ，可扩展的分析引擎支持更复 杂的数据挖掘和机器学习场景 MPP Massively Parallel Processing 架构，大规模集群 分布式存储及并行计 算， Shared Nothing 模式支 基础 设施 Docker/K8S/VM X86/ARM - 基于 RUST 语言保证性能优势 - 分布式架构性能可线性扩展 - 针对大规模图优化的存算引擎 - 配合 Atlas 图平台，实现无代码图分析 - Query 性能分析模块，启发式提示优化 - 内置多种分析函数，面向分析师友好 -MVOCC 保证事务一致性 - 多副本管理保证数据服务高可用 - 在线备份提供容灾保障 图技术简介 Takeway AtlasGraph 图数据库关键特性 - 基于 RUST 语言保证性能优势 - 分布式架构性能可线性扩展 - 针对大规模图的优化的存算引擎 - 配合 Atlas 图平台，实现无代码图分析 - Query 性能分析模块，启发式提示优化 - 内置多种分析函数，面向分析师友好 -MVOCC 保证事务一致性 - 多副本管理保证数据服务高可用 - 在线备份提供容灾保障

VARCHAR(24)) TDengine - 业务模式 开源版 企业版 云服务版 核心功能开源 • SQL 支持 • 无模式写入 • 缓存 • 流计算 • 数据订阅 • 集群、高可用 高可靠、线性扩展 + 专业技术服务 • 边云数据复制 • 跨云 / 异地数据复制 • 增量备份 • 多级存储 • 工业数据接入 全托管时序数据 管理云服务平台 • 全托管服务 • VPC 对等连接 自 我 介 绍 T D e n g i n e t a o s X R u s t 使 用 taosX - 物联网数据接入问题 • 多种不同协议数据对接，开发复杂度高 • 模块之间关联性不高但模块组成复杂，可维护性差 • 大量设备大量数据归集存储，存储压力大 • 数据总线 / 消息队列消息接入，定制化程度要求高 • 数据业务逻辑自定义需求强 • 一定的实时数据分析能力 taosX

当代： C++17 引入常用数值算法 未来： C++20 引入区间（ ranges ） https://zhuanlan.zhihu.com/p/350068132 未来： C++20 引入模块（ module ） https://zhuanlan.zhihu.com/p/350136757 未来： C++20 允许函数参数为自动推断（ auto ） 未来： C++20 引入协程（ coroutine format 支持 跑远了！ • 鉴于 C++20 还没有普遍落地（例如 CMake 不支持 C++20 modules ）因此我们的课程 基于 C++17 标准，有时会谈到 C++20 作为扩展阅读。 C++ 有哪些面向对象思想？ C++ 思想：封装 比如要表达一个数组，需要：起始地址指针 v ，数组大小 nv 将多个逻辑上相关的变量包装成一个类 因此 C++ 的 vector 将他俩打包起来，避免程序员犯错 ，才发展出了这些思 想，并将拷贝 / 移动 / 指针 / 可变性 / 多线程等概念作为语言基本元素存在。这些在我们的 业务里面是非常重要的，所以不可替代。 • （试图升华文章中心主旨） 扩展阅读关键字 • 限于篇幅，此处放出一些扩展知识供学有余力的同学研究： 1. P-IMPL 模式 2. 虚函数与纯虚函数 3. 拷贝如何作为虚函数 4. std::unique_ptr::release() 5

四维协同基线，沉 淀全流程数据，从感知到赋 能，服务于工程师 释放云基建能力：链接任何云 及自建资源（容器、主机、车 机、端等），释放云原生价值 和企业创新力 生态开放：广泛开放系统 模块和 OpenAPI ，链接 一切流程、服务、工具和 上下游伙伴 安全简单自主可控：私有化 部署，现有服务 0 迁移成本 、体验丝滑接入容易、学习 使用门槛极低 现存做法大多以「单点工具 和最佳实践，基于平台工程打造，可以轻松连 接一切工具链 企业自建 DevOps 流程平台 围绕 Jenkins 或 CI/CD 工具 搭建流程串接胶水平台 局限性大扩展性差 内部推广难度极高 做完后价值难被证明 通用性、可扩展性、技术先进性强，可以灵活 广泛接入各种技术和业务场景 基于代码管理的 DevOps 方案 Gitee 平台 GitLab 平台 局限性大、全流程安全性低 维护成本高

Fortran GNU gcc g++ gfortran LLVM clang clang++ flang 多文件编译与链接 • 单文件编译虽然方便，但也有如下缺点： 1. 所有的代码都堆在一起，不利于模块化和理解。 2. 工程变大时，编译时间变得很长，改动一个地方就得全部重新编译。 • 因此，我们提出多文件编译的概念，文件之间通过符号声明相互引用。 • > g++ -c hello.cpp -o 这样当预处理器第二次读到同一个文件时，就会自动跳过 • 通常头文件都不想被重复导入，因此建议在每个头文件前加上这句话 头文件进阶 - 递归地使用头文件（再续） （自动跳过） CMake 中的子模块 • 复杂的工程中，我们需要划分子模块，通常一个库一个目录，比如： • 这里我们把 hellolib 库的东西移到 hellolib 文件夹下了，里面的 CMakeLists.txt 定义了 hellolib 的生成规则。 ，其中定义的库在 add_subdirectory 之后就可以在外面使用。 • 子目录的 CMakeLists.txt 里路径名（比如 hello.cpp ）都是相对路径，这也是很方便的一 点。 子模块的头文件如何处理 • 因为 hello.h 被移到了 hellolib 子文件夹里，因此 main.cpp 里也要改成： • 如果要避免修改代码，我们可以通过 target_include_directories

CMake 中使用： find_package CMake 中使用：作为子模块 这个什么“勾勾”公司非要默认开启 tests ，导致需要去寻找 googletest ，妨碍了我们作为子模块使用。 小彭老师单方面宣布：一切默认开启 tests ， docs 构建目标的 cmake 项目，有病啊！ 你妨碍别人作为子模块用你的项目。没错说的就是你 OpenSim ，张心欣当时浪费好多时间伺候这个沙雕库。

Python 作为老牌胶水语言，为了 用户体验做了些特殊处理。他的 ast 模块能自动识别 [] 位于等号左侧还是右侧，分成两个独立的函数 。 • 如果等号在左侧，则被他的 ast 模块视为写入上下文（ store context ），翻译成 __setitem__ 。 • 如果等号在右侧，则被他的 ast 模块视为读取上下文（ load context ），翻译成 __getitem__ 。