Answers:
免责声明:我在Bazel上工作,但对Gradle并不十分熟悉。但是,我的一位同事写了两个系统的比较,我将在这里解释一下:
Bazel和Gradle强调了构建体验的不同方面。在某种程度上,它们的优先级是不兼容的-Gradle对灵活性和非干扰性的需求限制了它对构建结构的限制,而Bazel对可靠性和性能的渴望必然会强制实施不可协商的限制。
Gradle确实重视与Bazel相同的原则,即Gradle团队非常重视性能(增量构建,并行化配置和执行,Gradle守护程序),正确性(基于内容的“最新”检查)和可重复性(对声明性语法,依赖项版本控制,显式声明的依赖项的丰富支持)。Bazel尊重对灵活项目布局的需求。
细微的差别是,Gradle希望推广良好做法,而Bazel则要求这样做。Gradle的目标是在Ant经验(自由定义具有不一致结果的项目结构)和Maven经验(强制性最佳实践,不能满足项目需求的余地)之间取得中间立场。Bazel相信,在不牺牲强大功能保障的前提下,灵活的项目支持是可能的。
两种哲学都不是“正确的”-哪种工具最适合项目取决于该项目的价值。
Gradle是一个高度灵活的系统,它使用户可以轻松构建完整,可靠的构建流程,而对组织项目的方式的限制则最小。它通过提供功能强大的构建块(例如,自动依赖项跟踪和检索,紧密集成的插件支持)以及通用的,图灵完备的脚本编写界面来实现此功能,该界面可以根据用户的需要组合这些块。
Gradle强调以下功能:
Bazel摆脱了可靠,高效地构建内部Google项目的需求。由于Google的开发环境异常庞大且复杂,因此Bazel为其构建的完整性提供了非同寻常的有力保证,而在实现它们方面的性能开销却异常低。
这为围绕可重现的构建构建强大的开发工作流提供了基础,其中“构建”成为一个抽象实体,可以对其进行引用,重复,传递给不同的机器,并传递给任意程序和服务,从而使每个实例都被认为是完全相同的。
Bazel强调以下功能:
随着文章链接的消失,以下是Gradle团队对Bazel观点的摘要(大部分直接摘自于2015年3月发布的文章):
它旨在解决Google独有的问题;庞大的整体代码库(亿万LOC)。
Bazel当前提供的并行化优势将与“我们即将推出的新配置和组件模型”相匹配(请记住此处的文章日期)。
Bazel没有高级的声明性构建语言,该语言使开发人员易于使用该构建。在Google,这可以由拥有构建工具的专业服务团队来补偿。
Bazel并不是为可扩展性而构建的(尽管从那时起,Bazel开发团队就以保证可扩展性为目标进行了反击)。
围绕所有传递依赖项都存储在一个大型仓库中的想法优化了速度。所有库和工具都签入到此中央存储库。大多数企业具有更多的分布式依赖管理要求。
Bazel仅* nix,不能在Windows上运行。这消除了大量潜在的企业。
没有插件生态系统。
Gradle主要用于JVM生态系统(Java,Ggroovy,Scala,Kotlin等)。如果您的项目在这一领域,而您不得不问这个问题,那么Gradle或Maven将是一个更好的选择。要对Gradle构建进行故障排除,您将只使用Java和JVM生态系统。
Bazel的核心功能是能够检测增量更改(以及分布式构建缓存),并允许您做出反应,应用插件/规则来实现增量构建。要设置和维护此内容,需要具备CPP,Java和Python(Skylark)的一些知识以及System Admin的知识。同样,如果您不得不问这个问题,我认为Gradle或Maven会是一种便宜的投资。使用Bazel,您可以以您定义的任何方式构建任何一种语言,以增强功能,但要付出一定的代价。