在项目开发过程中，避免不了要使用一些开源的三方库，我参加过的一些团队有不同的管理三方库的方式。不同的方式都各有优缺点，我们先列举一下碰到过的管理方式，说一些他们的优缺点，最后再来讨论我们今天介绍的管理方式弥补了哪些缺点。

统一管理三方库

一些团队是直接将三方库编译好放到 CI 机器上，在本地开发或者 CI 出项目的 Release 包时去做依赖拷贝。这样做有以下几点好处：

1. 三方库不需要每次都重新编译，需要时拷贝，包括符号调试文件也可以一并维护。
2. 大家公用一份三方库，确保三方库的出处都是一样的。

但是这样管理也有一些不足。

1. 如果不同的项目需要依赖不同版本、不同分支的三方库，则统一的管理无法满足需求
2. 三方库的版本管理迭代会保留诸多历史文件，一旦历史版本被清理则很难追溯历史缺陷的符号调试文件

上传三方库文件到 Git 中

编译好直接上传到项目的仓库中，这种方式有一些好处，比如：

1. 工程下载下来不需要多余配置，启动 IDE 直接编译不废话。
2. 自己想依赖什么版本就什么版本，不受限于其他项目

当然缺点显而易见：

1. 静态库文件编译后非常大，上传到 Git 仓库中仓库会异常庞大，特别是三方库二进制文件的更新。
2. 这种形式很容易出现源码和三方库文件不匹配的情况，这个项目编译好的复制到其他项目直接用，管理混乱。
3. 跨平台项目要上传不同平台的三方库二进制文件到工程中

使用 CMake + Git Submodule 形式管理

通过以上的描述，我们已经很容易能看清楚不同的管理方式的优劣了。本文推荐的方法可以弥补一些上面方式的不足，但可能也因不同团队而异。推荐的方式大概分以下步骤。

1. 将你需要依赖的三方库设置为 Git Submodule，每个项目可以依赖不同版本的三方库，不需要上传二进制文件。
2. 脚本利用 CMake 自动编译三方库工程，不同平台可以使用 CMake 自动编译，不需要单独维护个别版本。
3. CI 出 Release 时自动编译三方库并保留匹配版本的调试符号文件，和本地源码原始匹配不易混乱。

我们以一个 libyuv 三方库举例。首先将项目添加为 Git Submodule

git submodule add https://chromium.googlesource.com/libyuv/libyuv third_party/libyuv

添加完成后，我们写一个自动编译三方库的脚本，Windows 平台下使用批处理、macOS 下使用 Shell 脚本。

# Windows: Generate visual studio solution
cmake -H. -Boutput -G"Visual Studio 15 2017"
# Build release library
cmake --build output --config Release --target yuv
# Build debug library
cmake --build output --config Debug --target yuv

# macOS: Generate makefile
cmake -H. -DCMAKE_MACOSX_RPATH=OFF -DCMAKE_BUILD_TYPE=Release -Boutput -G"Unix Makefiles"
# Static library
cmake --build output --target yuv

这样在不同平台我们就可以自动编译三方库二进制文件了，本地开发时只需要将 Submodules 更新下来，头文件和库文件路径都修改为三方库文件的路径。CI 出 Release 包时也是先将 Submodules 更新下来编译后再编译项目主体。