jank-lang项目移除vcpkg依赖的技术决策与实践

背景与决策动机

在jank-lang项目的开发过程中，团队最初选择了vcpkg作为C++依赖管理工具。然而，随着项目的发展，团队发现vcpkg在实际使用中存在多个关键问题：

1. 跨平台兼容性问题：vcpkg未能完全兑现其跨平台兼容性的承诺，部分依赖项在某些平台上构建失败
2. 与Nix的兼容性：项目需要与Nix包管理器配合使用时遇到障碍
3. CMake工具链复杂性：vcpkg增加了CMake构建系统的复杂度
4. 架构支持不足：无法正确处理x86_64和arm64架构的三元组分离问题

基于这些技术痛点，团队决定彻底移除vcpkg，采用更灵活、可控的依赖管理方案。

替代方案设计

团队对原有vcpkg.json中列出的所有依赖项进行了详细分析，制定了分类处理策略：

1. 系统级包管理：对于广泛存在于各Linux发行版仓库中的成熟库，直接使用系统包管理器安装
2. 子模块集成：对于头文件库或需要特定版本的库，采用Git子模块方式引入项目
3. 源码构建：对于需要编译的依赖项，作为外部项目集成到CMake构建系统中

具体实施细节

系统级包管理处理

以下依赖项转为使用系统包管理器安装：

• Boost相关组件(algorithm, filesystem, smart-ptr, variant, preprocessor)
• fmt库
• readline库

这些库在主流Linux发行版中都有良好维护的软件包，通过系统包管理器安装能确保最佳兼容性。

子模块集成方案

对于头文件库，团队选择将它们作为Git子模块引入项目：

1. CLI11：命令行参数解析库，纯头文件实现
2. immer：持久化数据结构库，纯头文件实现
3. magic-enum：枚举反射库，纯头文件实现

这些子模块被统一放置在compiler+runtime/third-party/目录下，保持项目结构的清晰。

需要编译的依赖项处理

对于需要编译的依赖项，团队采用了更精细的管理方式：

1. bdwgc(Boehm-Demers-Weiser垃圾收集器)：

   • 作为子模块引入
   • 使用其自带的CMake构建系统
   • 集成到项目的主CMake构建流程中

2. libzippp：

   • 作为子模块引入
   • 通过CMake的ExternalProject机制构建
   • 处理了与zlib等底层依赖的关系

技术优势分析

移除vcpkg后，项目获得了以下技术优势：

1. 构建确定性增强：不再依赖外部包管理器的状态，所有依赖项版本被锁定在Git子模块中
2. 跨平台兼容性提升：各平台可以自由选择最适合的依赖安装方式
3. 构建流程简化：CMake脚本更简洁，减少了工具链的复杂度
4. 架构支持完善：能够正确处理不同CPU架构的构建需求
5. 与Nix的兼容性：项目现在可以无缝集成到Nix生态系统中

经验总结

这次架构调整为jank-lang项目带来了更健康、更可持续的依赖管理方案。关键技术收获包括：

1. 对于C++项目，依赖管理需要根据项目规模和目标平台谨慎选择方案
2. 混合使用系统包管理、子模块和源码构建可以取得灵活性与稳定性的平衡
3. 构建系统的简化对长期维护至关重要
4. 锁定依赖版本是保证可重现构建的关键

这一技术决策为jank-lang项目的长期发展奠定了更坚实的基础，特别是在跨平台支持和构建可靠性方面取得了显著进步。