Apache Arrow C++ 计算模块的编译条件优化

问题背景

在构建 Apache Arrow C++ 版本的基准测试时，开发者发现当启用 ARROW_BUILD_BENCHMARKS 选项但禁用 ARROW_COMPUTE 模块时，构建系统会报出 undefined reference to arrow::compute::Grouper::Make 的错误。这个问题源于构建系统配置中缺少对计算模块依赖关系的正确处理。

问题分析

Apache Arrow 是一个跨语言的开发平台，用于处理内存中的数据。其 C++ 实现采用了模块化设计，允许用户根据需要选择编译特定功能模块。在这个案例中：

1. grouper_benchmark 基准测试依赖于 arrow/compute/row 模块中的 Grouper 类
2. 当前构建配置无条件地将基准测试添加到构建系统中
3. 当计算模块被禁用时，相关符号自然无法找到，导致链接错误

解决方案

通过为基准测试添加条件编译检查，可以优雅地解决这个问题。具体修改是在 cpp/src/arrow/compute/row/CMakeLists.txt 文件中，将无条件添加基准测试的语句改为有条件添加：

if(ARROW_COMPUTE)
  add_arrow_benchmark(grouper_benchmark PREFIX "arrow-compute")
endif()

这种修改确保了：

1. 当计算模块启用时，基准测试会被正常构建
2. 当计算模块禁用时，构建系统不会尝试构建依赖它的基准测试
3. 保持了构建配置的灵活性和模块化特性

最佳实践建议

对于类似的多模块项目，建议：

1. 显式声明依赖：每个测试/基准测试应明确声明其依赖的模块
2. 条件编译：使用 CMake 的条件语句确保只有在满足依赖时才构建目标
3. 模块化设计：保持各功能模块的独立性，便于按需启用/禁用
4. 构建选项文档：清晰记录各构建选项的相互依赖关系

这种处理方式不仅解决了当前的构建错误，还为项目的长期维护提供了更好的可扩展性，使其他开发者能够更灵活地配置构建选项而不遇到意外错误。

总结

通过对构建系统的这一小处但关键的修改，Apache Arrow 项目进一步提升了其构建系统的健壮性。这种处理方式展示了大型开源项目如何通过精细的模块化设计和条件编译来管理复杂的依赖关系，值得其他类似项目借鉴。