在跨平台开发中，我们经常会在 CMake 项目中使用第三方库，如 zlib。当我们使用的是该库的动态链接版本（即 .dll），则需要特别处理运行时依赖问题。
一、项目背景结构概览
-
MyDBPool是一个静态库（STATIC），但它内部链接了一个第三方动态库zlib.dll（通过zlib.dll.a）。 -
Server是一个最终的可执行文件（add_executable），它依赖MyDBPool。
项目结构简化如下：
MyProject/
├── tools/zlib/libs/zlib.lib # 动态库的 import lib
├── tools/zlib/libs/zlib.dll # 动态链接库本体
├── MyDBPool/
│ └── CMakeLists.txt
├── Server/
│ └── CMakeLists.txt
二、静态库是否可以拷贝 DLL？
错误写法示例：
# ❌ 错误：不能对静态库使用 POST_BUILD
add_custom_command(TARGET MyDBPool POST_BUILD ...)
静态库在链接阶段并不会执行，它只是代码和符号的集合。因此，对其添加 POST_BUILD 命令并没有意义，也无法触发。
正确写法：
# ✅ 正确：在最终可执行文件上执行 DLL 拷贝
add_custom_command(TARGET Server POST_BUILDCOMMAND ${CMAKE_COMMAND} -E copy${ZLIB_DLL}$<TARGET_FILE_DIR:Server>)
只有最终生成的可执行文件或者 DLL，才需要在构建完成后做运行时环境准备。
三、zlib.lib 与 zlib.dll 的关系
很多开发者对 .lib 文件存在误解。其实：
| 文件 | 说明 |
|---|---|
zlib.lib | 是 zlib.dll 的 import library，编译时使用 |
zlib.dll | 是动态库的本体，运行时必须存在 |
当你在 CMake 中使用 target_link_libraries 链接 zlib.lib 时，其实只是告诉编译器该用哪些外部函数地址，真正执行时仍然依赖 zlib.dll。
四、静态库内部链接动态库，对上层的影响
虽然 MyDBPool 是一个静态库，但它内部链接了 zlib.dll，因此：
-
MyDBPool编译时需要zlib.lib -
运行时真正使用它的
Server必须带上zlib.dll
这是 C++ 项目中非常容易忽略的问题：静态库看似“自包含”，但其实可能悄悄埋下了运行时依赖。
五、进一步延伸：更优雅的 DLL 拷贝方案
为了避免每个可执行项目都手动写 DLL 拷贝逻辑，可以封装为一个函数：
function(copy_runtime_dll TARGET_NAME DLL_PATH)if(WIN32)add_custom_command(TARGET ${TARGET_NAME} POST_BUILDCOMMAND ${CMAKE_COMMAND} -E copy_if_different${DLL_PATH} $<TARGET_FILE_DIR:${TARGET_NAME}>)endif()
endfunction()# 使用方式：
copy_runtime_dll(Server ${ZLIB_DLL})
这让整个项目的 CMakeLists.txt 更加清晰、可维护。
六、总结
| 问题 | 正确做法 |
|---|---|
| 静态库链接动态库后，谁负责 DLL？ | 是最终的可执行文件负责 DLL 的拷贝 |
| 是否能对静态库添加 POST_BUILD？ | 否，只能对可执行文件或动态库目标执行 |
zlib.lib 是否是静态链接？ | 否，它是 zlib.dll 的 import library（动态链接） |
在 CMake 中处理动态库尤其是在 Windows 平台，需要特别关注链接时和运行时的分离逻辑。合理使用 POST_BUILD 与 DLL 拷贝机制，可以极大提升跨平台构建体验。
如果你在开发过程中使用了其他第三方 DLL（如 OpenSSL、MySQL 等），同样可以套用本篇的方法论来处理。
写好 CMake，是一个现代 C++ 工程师的基本功。