27、CPack中的版本管理：版本号设置、版本文件生成、版本兼容性检查

版本管理这件事，说大不大，说小不小。我见过不少项目，代码写得漂漂亮亮，结果一打包，版本号乱成一锅粥。要么是忘了更新，要么是不同模块版本对不上。今天咱们就把CPack里的版本管理彻底捋清楚。

版本号设置：从CMakeLists.txt说起

版本号的源头，其实在CMakeLists.txt里。我个人习惯用project()命令直接定义：

cmake_minimum_required(VERSION 3.16)
project(MyApp VERSION 1.2.3 LANGUAGES CXX)

这样CMake会自动生成几个变量：

• PROJECT_VERSION → "1.2.3"
• PROJECT_VERSION_MAJOR → 1
• PROJECT_VERSION_MINOR → 2
• PROJECT_VERSION_PATCH → 3

然后在CPack配置里，直接引用这些变量：

set(CPACK_PACKAGE_VERSION "${PROJECT_VERSION}")
set(CPACK_PACKAGE_VERSION_MAJOR "${PROJECT_VERSION_MAJOR}")
set(CPACK_PACKAGE_VERSION_MINOR "${PROJECT_VERSION_MINOR}")
set(CPACK_PACKAGE_VERSION_PATCH "${PROJECT_VERSION_PATCH}")

版本文件生成：让用户知道他用的是啥

打包后的软件，总得有个地方能查到版本号吧？我见过最离谱的情况，是用户装完软件不知道版本，只能去翻编译日志。

CPack支持在安装时自动生成版本文件。常用的做法有两种：

方法一：使用CPack的版本文件模板

set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_SOURCE_DIR}/LICENSE")
set(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_SOURCE_DIR}/README.md")
# 版本信息会嵌入到包的元数据中

方法二：手动生成版本头文件

我个人更推荐这种方式，因为更可控：

configure_file(
  "${CMAKE_SOURCE_DIR}/version.h.in"
  "${CMAKE_BINARY_DIR}/version.h"
  @ONLY
)
install(FILES "${CMAKE_BINARY_DIR}/version.h" DESTINATION include)

其中version.h.in的内容：

#define APP_VERSION "@PROJECT_VERSION@"
#define APP_VERSION_MAJOR @PROJECT_VERSION_MAJOR@
#define APP_VERSION_MINOR @PROJECT_VERSION_MINOR@
#define APP_VERSION_PATCH @PROJECT_VERSION_PATCH@

版本兼容性检查：别让用户掉坑里

版本兼容性检查，说白了就是防止用户装错版本。比如你的库1.x和2.x的API不兼容，用户拿1.x的程序链接2.x的库，那肯定崩。

CPack本身不直接做运行时兼容性检查，但我们可以通过包命名和依赖声明来规避问题。

包命名策略

我建议把主版本号放进包名：

set(CPACK_PACKAGE_NAME "MyApp-${PROJECT_VERSION_MAJOR}")
set(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${PROJECT_VERSION}")

这样生成的文件名是MyApp-1-1.2.3.deb，用户一看就知道是1.x系列。

依赖版本声明

对于Debian系，可以用：

set(CPACK_DEBIAN_PACKAGE_DEPENDS "libfoo (>= 2.0), libbar (<< 3.0)")

对于RPM系：

set(CPACK_RPM_PACKAGE_REQUIRES "libfoo >= 2.0, libbar < 3.0")

运行时版本检查：最后的防线

我曾经维护过一个底层库，用户总喜欢从GitHub直接拉源码编译，跳过包管理器。结果版本不匹配的问题层出不穷。

后来我在库的初始化函数里加了版本检查：

// 库导出的版本检查函数
bool checkVersion(int requiredMajor, int requiredMinor) {
    if (requiredMajor != APP_VERSION_MAJOR) {
        fprintf(stderr, "版本不兼容！需要主版本 %d，当前主版本 %d\n",
                requiredMajor, APP_VERSION_MAJOR);
        return false;
    }
    if (requiredMinor > APP_VERSION_MINOR) {
        fprintf(stderr, "版本过旧！需要次版本 %d，当前次版本 %d\n",
                requiredMinor, APP_VERSION_MINOR);
        return false;
    }
    return true;
}

然后在应用程序里调用：

if (!checkVersion(1, 3)) {
    exit(EXIT_FAILURE);
}

嗯，这招虽然粗暴，但确实管用。用户再也没来找我抱怨过"装上了但跑不起来"。

版本管理的整体流程

说了这么多，咱们用一张图把整个流程串起来：

你看，版本管理不是单一环节，而是一条链。从定义到生成，再到打包和检查，每一步都马虎不得。

做到这几点，版本管理这块基本就稳了。下次用户再问"我装的是哪个版本"，你就能自信地告诉他：看包名就知道了。