1、CPack入门：什么是CPack、CPack在CMake生态中的角色、CPack与传统打包工具对比
1.1 什么是CPack？说白了就是个打包管家
CPack，全称是CMake Packager。嗯，名字挺直白的——它就是CMake家族里专门负责打包的那个工具。
我刚开始接触CMake时，一直以为CMake只能生成Makefile或者Visual Studio工程。后来有个项目需要把编译好的库分发给客户，我才发现CMake自带了一个打包工具，就是CPack。说实话，当时挺惊喜的。
CPack的作用很简单：把你编译好的二进制文件、头文件、配置文件、文档等，打包成各种格式的安装包。比如Linux下的deb、rpm，Windows下的NSIS安装包，macOS下的DMG，或者跨平台的tar.gz压缩包。
你想想看，如果没有CPack，你要怎么做？手动写脚本？用不同的工具打不同的包？维护多套打包逻辑？那画面太美我不敢看。
一句话总结：CPack是CMake生态中的打包引擎，让你用一套配置，打出多种格式的安装包。
1.2 CPack在CMake生态中的角色
CMake生态里，有三个核心工具：CMake、CTest、CPack。它们的关系是这样的：
从这张图你能看出来：
- CMake 负责配置项目、生成构建文件。它定义了
install()规则——哪些文件要安装到哪个目录。 - CTest 负责跑测试。它和CPack是平级关系，各管各的。
- CPack 负责打包。它读取CMake里的
install()规则，然后生成安装包。
我个人习惯把CMake比作「总设计师」，CTest是「质检员」，CPack是「包装工」。设计师画好图纸（CMakeLists.txt），质检员检查质量（CTest），包装工把成品打包发货（CPack）。
小提示：CPack并不重新编译你的代码。它只负责把已经编译好的产物打包。所以打包前，你得先确保项目已经编译通过了。
1.3 CPack与传统打包工具对比
说到打包，你可能会想到一堆工具：Linux下的dpkg-deb、rpmbuild，Windows下的NSIS、WiX Toolset，macOS下的pkgbuild……每个平台都有自己的打包工具。
那CPack和它们比，优势在哪？我列个表给你看：
| 对比维度 | CPack | 传统工具（dpkg/rpm/NSIS） |
|---|---|---|
| 配置方式 | CMake语法，与构建系统统一 | 各自独立的脚本/配置文件 |
| 跨平台能力 | 一套配置，多格式输出 | 每个平台需要单独写配置 |
| 与CMake集成 | 天然集成，直接复用install()规则 | 需要手动处理文件列表 |
| 学习成本 | 低（会CMake就会CPack） | 高（每种工具都要学） |
| 灵活性 | 中等（封装了底层细节） | 高（直接操作底层） |
| 维护成本 | 低（改一处，多格式生效） | 高（每个平台配置独立维护） |
说白了，CPack最大的价值就是「一次配置，到处打包」。你想想看，如果你的项目要同时发布Linux deb包、Linux rpm包、Windows exe安装包、macOS dmg镜像，用传统工具你得维护四套打包脚本。用CPack呢？一套CMake配置就够了。
我在项目中遇到过这样的情况：一个跨平台库，客户要求同时提供deb和rpm包。如果用传统方式，我得学dpkg和rpm两套打包语法。用CPack，我只需要在CMakeLists.txt里加几行：
# 启用CPack
include(CPack)
# 设置包信息
set(CPACK_PACKAGE_NAME "MyLib")
set(CPACK_PACKAGE_VERSION "1.0.0")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "My Awesome Library")
# 指定生成格式
set(CPACK_GENERATOR "DEB;RPM")然后运行：
# 先编译
cmake -B build
cmake --build build
# 打包
cd build
cpack -G DEB # 生成 .deb 包
cpack -G RPM # 生成 .rpm 包搞定。是不是很省事？
注意：CPack虽然方便，但它不是万能的。如果你需要非常复杂的安装逻辑（比如自定义安装界面、条件安装、注册表操作等），CPack的抽象层可能会成为限制。这时候你可能需要直接使用底层工具，或者用CPack的postinstall脚本做补充。
1.4 什么时候该用CPack？
根据我的经验，以下场景特别适合用CPack：
- 跨平台项目：需要同时发布多个平台的安装包
- CMake项目：已经在用CMake管理构建，加CPack几乎没有额外成本
- 标准安装需求：安装逻辑比较简单（复制文件、创建目录、设置权限）
- 持续集成：CI/CD流水线中自动打包，CPack的命令行接口非常友好
反过来，如果你的项目有非常特殊的安装需求，或者你只需要打一种包（比如只打deb包），那直接用原生工具可能更灵活。不过话说回来，我个人的建议是：只要你的项目在用CMake，就值得试试CPack。哪怕只打一种格式，CPack也能帮你省掉不少重复劳动。
我的经验：刚开始用CPack时，我犯过一个低级错误——忘了在CMakeLists.txt里写install()命令。结果打包出来的东西是空的。嗯，CPack只打包你通过install()指定的文件，不会自动把整个构建目录塞进去。这个坑我替你们踩过了。
1.5 小结
这一章我们聊了：
- CPack是CMake生态里的打包工具，负责生成安装包
- 它在CMake生态中与CMake、CTest各司其职
- 相比传统打包工具，CPack的优势是跨平台、配置统一、与CMake深度集成
- 适合跨平台项目、CMake项目、标准安装需求
下一章，我们会动手搭建一个实际项目，从零开始配置CPack。到时候你会看到，原来打包可以这么简单。