Scala构建工具SBT vs CBT [关闭]

Question

我目前正在使用 SBT 构建我的 scala 项目，但最近我了解到另一个名为 CBT 的构建工具。

我从 CBT 文档中看到的一个明显优势是，编写构建文件与编写 scala 代码一样好。

我想从使用过的人那里了解这两种构建工具的优缺点，例如性能、构建时间等。

Answer 1

我是 CBT 的作者。

TL；DR CBT 在某些领域更简单、更快，但更年轻且实践证明较少。

长版：

CBT 旨在比 SBT 更易于使用，同时与 Maven 或 Ant 等旧工具相比，在表现力方面具有相似的优势。我相信 CBT 可以在这里实现。在引用任务（方法）时，它还为您提供类型安全性，其中在 SBT 中，任务可能会或可能不会在您正在阅读的范围内定义。性能方面的 CBT 具有更快的 bash 启动时间（大约 100 毫秒），并通过操作系统推送通知而不是 SBT 的 0.5 秒间隔轮询来立即对文件更改做出反应。

在这一点上，CBT 的实践证明不如 SBT，您可能会发现一些粗糙的边缘。特别是现在我打算尽快更改的文档很少。您还将在网上找到更少的 CBT 构建示例。然而，CBT 的仓库中有示例文件夹和测试。您可能还会发现一些 wrt 插件的盲点。所有的 linter、代码格式化程序、编译器、发布插件都存在。打包和 IDE 支持仍需要重大改进。插件非常容易编写和添加。

CBT 的源代码在概念上非常简单，对初学者友好且易于贡献，部分原因是 CBT 在更改后会自动重建自身，使其立即可用。 SBT 的代码库更难掌握，我不知道如何实际使用本地更改的代码库，我想部署快照构建。

CBT 目前不会同时运行任务或构建项目。它可能永远不会对项目中的任务执行此操作，但可能会为不同的子项目启动并发编译。 SBT 尽可能（或假设可能）并行化任务。我不认为 CBT 的表现会因不这样做而受到影响。总体来说非常活泼。

CBT 尚未在大型项目中进行实战测试。 CBT 本身是一个多项目构建，包含超过 10 个子项目，但这可能是迄今为止尝试过的最大的项目。

所以现在（这在数周和数月内迅速改善）如果您选择 CBT，请准备好阅读大量源代码，使用 gitter 频道与我们交谈，而不是使用 IDE 或自行配置，帮助修复尚未有人费心修复的较小的、肤浅的可用性错误。

如果您想要精巧、支持更好、文档更丰富、更复杂的工具，其中包含更多可复制和可粘贴的示例以及更多在线插件，请选择 SBT。如果您想要一个更简单、更易于使用、更快速、几乎没有文档的工具，其代码库您可以快速理解，但有时您可能需要暂时修复自己，请选择 CBT。

最近还有这个关于 CBT 的视频：https://youtu.be/-2aMaAPQ35s