Scala構建工具SBT vs CBT

Question

我目前使用SBT構建我的scala項目，但是最近我瞭解到另一個構建工具CBT。

我從CBT文檔中看到的一個明顯的優點是，編寫構建文件與編寫scala代碼一樣好。

我想知道從使用它的人那裏獲得的性能，編譯時間等構建工具的比較優缺點。

Answer 1

我是CBT的作者。

TL; DR CBT在某些領域更簡單，速度更快，但更年輕，實踐證明也更少。

長版本：

CBT的目標是顯著簡單得多SBT時要使用比較老的工具，如Maven的螞蟻或讓步表現類似的好處。我相信CBT在這裏交付。它還可以在引用任務（方法）時爲您提供類型安全性，其中在SBT中，任務可能會或可能不會在您正在閱讀的範圍中定義。性能明智的CBT從bash啓動時間更快（大約100ms），並通過操作系統推送通知立即響應文件更改，而不是SBT的0.5s間隔輪詢。

CBT在這一點上不如SBT實踐證明，您可能會發現一些粗糙的邊緣。特別是現在我很少有文件，我希望儘快改變。您還可以在網上找到更少的CBT構建示例。然而，CBT的回購中有示例文件夾和測試。你也可能會發現一些關於插件的盲點。所有的linters，代碼格式化器，編譯器，發佈插件都存在。封裝和IDE支持仍需要重大改進。插件非常易於編寫和添加。

CBT的源代碼在概念上非常簡單，易於貢獻的初學者友好代碼，部分原因是CBT在發生變化後自動重建，從而使其立即可用。 SBT的代碼基礎很難掌握，我不知道如何實際使用本地更改的代碼，我想部署快照構建。

CBT當前不會同時運行任務或構建項目。它可能永遠不會爲項目中的任務執行此操作，但可能會爲不同的子項目啓動併發編譯。 SBT儘可能地並行化任務（或假定可能）。我不認爲CBT的表現會因爲不這樣做而受到影響。總體來說，它非常活潑。

CBT尚未在大型項目上進行過戰役測試。 CBT本身是一個多項目構建，具有> 10個子項目，但這可能是迄今爲止嘗試的最大項目。

所以現在（如果你選擇CBT，那麼現在就會在幾周或幾個月內迅速提高）準備好閱讀它的大量源代碼，使用gitter通道與我們交談，不要使用IDE或自己配置它，可以幫助解決人們無法解決的更小，膚淺的可用性錯誤。

如果您希望獲得更精細，更好的支持，更多文檔，更復雜的工具以及更多的副本和可移植的示例以及更多插件，請使用SBT。如果您希望使用代碼庫更簡單，更易於使用，更快捷，幾乎沒有記錄的工具，您可以快速理解，但有時您可能需要現在就使用CBT來修復自己。

還有這個最近關於CBT視頻：https://youtu.be/-2aMaAPQ35s