一、CPack初探：什么是CPack、CPack在CMake生态中的角色、为什么需要组件安装
1.1 什么是CPack？一个打包工具的自白
CPack，说白了就是CMake家族里的打包专家。
你写完了C++代码，用CMake构建好了项目，生成了可执行文件、动态库、头文件……然后呢？怎么把这些东西发给用户？
我刚开始做项目时，都是手动打包的。把二进制文件复制出来，再写个压缩脚本，折腾半天。后来发现CMake自带了一个打包工具——CPack，这才算解放了双手。
CPack是CMake官方提供的跨平台打包工具。它能把你构建好的产物（二进制、库文件、配置文件、文档等）自动打包成各种格式：
- Linux：DEB（Debian系）、RPM（RedHat系）、TGZ（压缩包）
- macOS：DMG、PKG、TGZ
- Windows：NSIS安装包、WiX安装包、ZIP压缩包
你只需要在CMakeLists.txt里配置好打包规则，一条命令就能生成安装包。嗯，就是这么简单。
核心概念：CPack是一个打包生成器，它不负责编译，只负责把编译好的产物打包成可分发的格式。
1.2 CPack在CMake生态中的角色
CMake生态里，有三个工具经常一起出现：
| 工具 | 职责 | 类比 |
|---|---|---|
| CMake | 配置 + 构建 | 建筑师，设计图纸并盖楼 |
| CTest | 测试 | 质检员，检查楼有没有问题 |
| CPack | 打包 + 分发 | 搬家公司，把盖好的楼打包运走 |
我个人习惯把CMake、CTest、CPack称为「三件套」。它们分工明确：
- CMake负责把源码变成二进制
- CTest负责验证二进制是否靠谱
- CPack负责把靠谱的二进制变成安装包
你想想看，如果没有CPack，你每次发布版本都得手动写打包脚本。不同平台还得用不同的脚本——Linux用bash，Windows用PowerShell，macOS用……嗯，想想就头疼。
CPack把这一切统一了。你在CMakeLists.txt里写一次配置，就能生成所有平台的安装包。这才是真正的「一次配置，到处打包」。
小提示：CPack本身不生成安装包格式，它依赖外部的打包工具。比如生成DEB需要dpkg-deb，生成RPM需要rpmbuild，生成NSIS需要makensis。记得提前装好这些工具。
1.3 为什么需要组件安装？
好，现在问题来了：一个项目打包时，是不是所有东西都要塞进一个安装包里？
我遇到过这种情况：一个SDK项目，包含了开发库、运行时库、示例代码、文档、测试工具。如果全部打成一个包，用户只想跑个demo，却要下载几百兆的文档和测试工具。这体验太差了。
组件安装（Component Installation）就是解决这个问题的。
你可以把项目拆成多个组件：
- Runtime：运行时库，用户运行程序必须的
- Development：开发库，包含头文件和静态库
- Documentation：文档，API参考和用户手册
- Examples：示例代码，帮助用户快速上手
- Tools：辅助工具，调试或测试用的
每个组件可以独立打包、独立安装。用户需要什么就装什么，不用全盘接收。
为什么需要组件安装？三个核心原因：
- 减少体积：用户只下载需要的部分，节省带宽和磁盘
- 降低依赖：不同组件可能有不同的依赖关系，分开管理更清晰
- 灵活分发：可以针对不同用户群体提供不同的安装包
举个例子。我曾经参与过一个图像处理库的项目。这个库有核心算法模块、GPU加速模块、Python绑定模块、Qt界面组件。如果全部打成一个包，用户只想用Python调用一下，却要装Qt和CUDA，这显然不合理。
用组件安装后，我们分了四个组件：
core：核心算法，所有用户都需要cuda：GPU加速，只有N卡用户需要python：Python绑定，给数据科学家用gui：Qt界面，给桌面应用开发者用
用户按需选择，皆大欢喜。
注意：组件之间可能存在依赖关系。比如python组件依赖core组件。CPack允许你声明组件依赖，安装时会自动处理。这个我们后面会详细讲。
1.4 一个简单的例子：感受CPack
光说不练假把式。我们来看一个最简单的CMakeLists.txt，感受一下CPack怎么用。
cmake_minimum_required(VERSION 3.15)
project(HelloCPack VERSION 1.0.0)
# 添加一个可执行文件
add_executable(hello main.cpp)
# 安装规则：把hello安装到bin目录
install(TARGETS hello
RUNTIME DESTINATION bin)
# CPack配置
set(CPACK_PACKAGE_NAME "HelloCPack")
set(CPACK_PACKAGE_VERSION "1.0.0")
set(CPACK_PACKAGE_DESCRIPTION "一个简单的CPack示例")
set(CPACK_GENERATOR "TGZ") # 生成tar.gz压缩包
include(CPack)
然后执行：
mkdir build && cd build
cmake ..
cpack
你就会得到一个HelloCPack-1.0.0-Linux.tar.gz压缩包。解压后里面就是bin/hello这个可执行文件。
嗯，这就是CPack最基础的用法。但实际项目中，我们不会这么简单。你会遇到：
- 多个组件需要分别打包
- 不同平台需要不同格式
- 组件之间有依赖关系
- 需要自定义安装路径
这些内容，我们会在后面的章节逐一展开。
我的建议：刚开始接触CPack时，先从小项目入手。把单个可执行文件打包成功，再逐步添加组件、依赖、多平台支持。一口吃不成胖子，打包也一样。
1.5 本章小结
这一章我们聊了三个问题：
- CPack是什么：一个跨平台的打包工具，能把CMake构建产物打包成各种格式
- CPack的角色：在CMake生态中负责打包分发，和CMake、CTest组成三件套
- 为什么需要组件安装：减少体积、降低依赖、灵活分发
下一章，我们会深入CPack的配置体系，看看如何用CPACK_开头的变量来控制打包行为。到时候我会分享一些我在项目中踩过的坑——嗯，打包这事，坑还真不少。