Google Glog项目中的Bazel构建系统迁移问题解析

背景介绍

Google Glog是一个广泛使用的C++日志库，它采用了Bazel作为其构建系统。Bazel作为Google开源的构建工具，近年来正在进行从传统WORKSPACE模式向Bzlmod模块化构建系统的重大迁移。这一变革对许多依赖Bazel的项目产生了深远影响。

问题现象

在Windows平台的CI构建过程中，Glog项目遇到了构建失败的问题。错误信息显示系统无法解析@platforms仓库，提示"Both '--enable_bzlmod' and '--enable_workspace' are disabled"。这表明构建系统既没有启用新的Bzlmod模块系统，也没有启用传统的WORKSPACE模式。

技术分析

根本原因

问题的根源在于Bazel 8版本中默认禁用了WORKSPACE文件功能，这是Bazel团队推动项目向Bzlmod迁移的战略性举措。根据Bazel的发布计划：

• Bazel 8（2024年底）将默认禁用WORKSPACE
• Bazel 9（2025年底）将完全移除WORKSPACE支持

具体技术细节

1. 依赖解析失败：构建过程中需要访问@platforms仓库，这是一个提供跨平台构建支持的公共仓库，但系统无法找到它。

2. 构建配置冲突：错误信息表明项目既没有启用Bzlmod，也没有启用WORKSPACE，导致构建系统无法确定如何解析外部依赖。

3. 平台特定问题：此问题特别出现在Windows平台上，可能与平台相关的构建配置有关。

解决方案

Glog项目团队通过以下方式解决了这个问题：

1. 明确构建模式：在构建配置中明确指定使用WORKSPACE模式或迁移到Bzlmod。

2. 依赖管理：确保所有必要的依赖（如@platforms）在选定的构建模式下正确声明和配置。

3. CI配置更新：调整持续集成系统的构建参数，确保与项目选择的构建模式一致。

经验总结

这一事件为使用Bazel的项目提供了重要启示：

1. 及时跟进构建系统更新：Bazel正在经历重大架构变更，项目需要及时调整构建配置。

2. 跨平台测试重要性：构建问题往往在特定平台显现，全面的跨平台测试十分必要。

3. 依赖管理策略：随着构建系统的演进，依赖管理方式也需要相应调整，项目应建立清晰的依赖管理策略。

未来建议

对于仍在使用Bazel的传统WORKSPACE模式的项目，建议：

1. 尽快开始Bzlmod迁移评估
2. 建立构建系统更新的监控机制
3. 加强跨平台构建测试
4. 制定明确的依赖管理规范

通过这次事件，我们可以看到现代构建系统演进对项目的影响，也体现了及时跟进基础设施变更的重要性。