CMake成果打包

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

前言
- - 一、基础必备文件（开发阶段）
  - [二、如果 `mylib` 本身依赖其他库，是否需要额外打包？](#二、如果 mylib 本身依赖其他库，是否需要额外打包？)
  - - [1. 依赖"静态库"（`.a`/`.lib`）](#1. 依赖“静态库”（.a/.lib）)
    - [2. 依赖"动态库"（`.dll`/`.so`/`.dylib`）](#2. 依赖“动态库”（.dll/.so/.dylib）)
  - [三、完整打包清单（以 Windows 平台为例）](#三、完整打包清单（以 Windows 平台为例）)
  - 四、示例说明
  - 总结

前言

如果上面生成的mylib为动态库，如果想要拿给其他项目作为第三方库使用，把mylib.dll和mylib.h打包就可以了吗，如果mylib.dll生成本身就需要其他依赖库，那么打包时需要额外打包其他的吗

要将动态库 mylib 作为第三方库提供给其他项目使用，仅打包 mylib.dll 和 mylib.h 通常是不够的，具体需要包含的文件及依赖处理规则如下：

一、基础必备文件（开发阶段）

其他项目要编译并链接 mylib，至少需要以下文件：

头文件（mylib.h） ：包含 mylib 对外暴露的函数、类、宏等声明，其他项目编译时需要通过 #include 引用，否则无法知道如何调用 mylib 的功能。
动态库文件（mylib.dll）：运行时需要加载的实际二进制代码（Windows 平台）。
导入库文件（mylib.lib，Windows 特有） ：动态库在编译时会生成对应的导入库（.lib），其他项目在链接阶段 需要通过该导入库解析 mylib 中的符号（函数/变量地址），否则链接会失败。

注意：Linux 平台的动态库（.so）不需要单独的导入库，链接时直接使用 .so 文件即可；macOS 平台的动态库（.dylib）也类似。但 Windows 必须依赖 .lib 导入库才能完成链接。

二、如果 `mylib` 本身依赖其他库，是否需要额外打包？

需要分两种情况：

1. 依赖"静态库"（`.a`/`.lib`）

如果 mylib 编译时链接了静态库（例如 libxxx.a 或 xxx.lib），则静态库的代码会被嵌入到 mylib.dll 中 （动态库本身包含了静态依赖的代码）。此时，其他项目使用 mylib 时，不需要额外打包这些静态库 （因为依赖已被"合并"到 mylib.dll 中）。

2. 依赖"动态库"（`.dll`/`.so`/`.dylib`）

如果 mylib 编译时链接了其他动态库（例如 xxx.dll），则 mylib.dll 运行时会动态加载这些依赖的动态库 （不会将其代码嵌入自身）。此时，其他项目使用 mylib 时，必须同时提供这些依赖的动态库 ，否则会出现"找不到 xxx.dll"的运行时错误（例如 Windows 的"缺少xxx.dll"弹窗）。

三、完整打包清单（以 Windows 平台为例）

假设 mylib 是动态库，且依赖另一个动态库 xxx.dll，则提供给其他项目的完整文件应包括：

开发阶段：mylib.h（头文件） + mylib.lib（导入库） + mylib.dll（动态库） + 依赖的 xxx.dll（若有动态依赖）。
运行阶段（仅需部署到最终环境）：mylib.dll + 依赖的 xxx.dll（若有动态依赖）（头文件和导入库仅开发时需要）。

四、示例说明

假设 mylib 编译时链接了动态库 zlib.dll（压缩库），则：

其他项目开发时，需要 mylib.h（编译）、mylib.lib（链接）、mylib.dll（运行）、zlib.dll（mylib 运行依赖）。
如果只打包 mylib.dll 和 mylib.h，其他项目会出现：
- 链接错误（缺少 mylib.lib）；
- 即使手动跳过链接（不可能），运行时会因找不到 zlib.dll 而崩溃。

总结

基础必备：头文件（.h）、动态库（.dll）、导入库（.lib，Windows 必需）。
动态依赖：若 mylib 本身依赖其他动态库，必须同时打包这些依赖的动态库，否则无法运行。
静态依赖：无需额外打包（已嵌入 mylib.dll）。

因此，分发动态库时，需先明确其依赖链（通过 ldd 工具（Linux）、dumpbin 工具（Windows）或 otool 工具（macOS）可查看依赖），再完整打包所需文件。