Conan项目中的共享库依赖部署最佳实践

概述

在基于Conan的C/C++项目构建过程中，如何处理共享库(SO)依赖的部署是一个常见问题。特别是当多个可执行文件共享同一个第三方库时，如何优雅地管理这些共享依赖项的部署流程值得深入探讨。

典型场景分析

在实际开发中，我们经常会遇到以下架构：

• 一个核心的第三方供应商库（Vendor Library）
• 多个依赖该库的可执行文件
• 供应商库本身可能还依赖其他基础库

这种架构的特点是：

1. 供应商库更新频率低（可能每年仅更新1-2次）
2. 可执行文件迭代速度快，需要频繁部署
3. 共享库需要独立于可执行文件进行部署

传统部署方式的局限性

常见的做法是在构建可执行文件时使用runtime_deploy等部署器，但这会导致：

• 每次部署可执行文件都会重复部署共享库
• 无法实现共享库的独立版本管理
• 部署流程不够清晰和模块化

Conan提供的解决方案

1. 独立部署供应商库

通过Conan的install命令配合--requires参数，可以直接部署指定的包及其依赖：

conan install --requires=vendorlib/1.0 --deployer=direct_deploy

这种方式会：

• 仅部署指定的供应商库及其所有依赖项
• 将库文件输出到指定目录（如direct_deploy/vendorlib/lib/）
• 不影响后续可执行文件的独立部署

2. 自定义部署方法

对于更复杂的需求，可以在包的配方中实现deploy()方法：

def deploy(self):
    self.copy("*.so", dst="lib", src="lib")
    self.copy("*.h", dst="include", src="include")

这种方法允许：

• 完全控制部署的文件和目录结构
• 实现特定于包的部署逻辑
• 保持部署过程与构建过程解耦

3. 使用自定义部署器

创建专门的部署器可以实现：

• 统一的部署策略
• 复杂的文件过滤和重定向
• 跨团队的部署规范共享

最佳实践建议

1. 分层部署：将稳定的供应商库与频繁变更的可执行文件分开部署
2. 版本控制：为每个部署的库保留版本信息，便于追踪
3. 环境隔离：为不同环境（开发、测试、生产）配置不同的部署策略
4. 自动化集成：将部署流程集成到CI/CD管道中

实施示例

假设我们有一个供应商库myvendor/1.2.3，部署流程可以是：

1. 首先部署供应商库：

conan install --requires=myvendor/1.2.3 --deployer=full_deploy -g deploy

2. 然后部署可执行文件（不包含已部署的共享库）：

conan install --requires=myapp/1.0 --deployer=app_only

通过这种分层部署方式，可以实现：

• 共享库的单一部署和集中管理
• 可执行文件的快速迭代和独立更新
• 整体部署过程的清晰和可控

总结

在Conan项目中合理规划共享库的部署策略，能够显著提高构建和部署效率。关键在于理解Conan提供的各种部署机制，并根据项目特点选择最适合的组合方案。通过分离共享库和可执行文件的部署生命周期，可以实现更灵活、更可靠的持续交付流程。