3 ms·

buck2 is arguably the state of the art currently, it is developed by meta based on the learnings from their own buck tool and bazel(/blaze), and others: > The

by zokier 2y ago

buck2 is arguably the state of the art currently, it is developed by meta based on the learnings from their own buck tool and bazel(/blaze), and others: > The retroactively named Buck1 was a capable build system and is still in use today at Meta (although many users have migrated). Buck2 is a rewrite that aims to keep the best bits of Buck1 (with a high degree of target compatibility) but also borrows ideas from academic research and build systems, including Bazel, Pants, Shake, Tup, and more. https://buck2.build/docs/about/why/ https://buck2.build/docs/about/why/ I'd say the two main tradeoffs to consider is do you want something very general-purpose, or is something more specific to certain language(s) appropriate? and do you want mature ecosystem, or bleeding edge solution? Bazel/buck2 are very general and language agnostic, while something like nx is more focused on JS with some support for other languages. Bazel is pretty mature at this point, while with buck2 you might need to do more trailblazing yourself.

zellyn 2y ago
> do you want something very general-purpose, or is something more specific to certain language(s) appropriate? This. At work, we use Bazel for the Java monorepo, and it's great (although pants2 seems like it might be better? Dunno, never used it...). Folks can convert individual classes to Kotlin, as they like to do, and it all just works. The Go monorepo still uses standard Go tooling, with a couple makefiles and some scripts: there are certainly things that bazel/pants2 would do better, but the Go tooling is just so nice (and so fast) that there's a much higher activation energy required to give it up. [Edit: adding...] One note: probably the biggest thing about a monorepo is that you really need to invest in tooling to make your CI still go fast. Typically, that means (a) tracing out dependencies of a particular change, and testing only those things, and (b) partitioning the tests up intelligently and running them on lots of different machines. IIUC, you could potentially get around having to do any partitioning or dependency tracing yourself by just using Bazel, with a bunch of Bazel workers running in the cloud, and then just do `bazed test //...` and let Bazel figure it out. Otherwise, you're going to want to find or write something that divides your tests up.

by zokier 2y ago

zellyn 2y ago

> do you want something very general-purpose, or is something more specific to certain language(s) appropriate? This. At work, we use Bazel for the Java monorepo, and it's great (although pants2 seems like it might be better? Dunno, never used it...). Folks can convert individual classes to Kotlin, as they like to do, and it all just works. The Go monorepo still uses standard Go tooling, with a couple makefiles and some scripts: there are certainly things that bazel/pants2 would do better, but the Go tooling is just so nice (and so fast) that there's a much higher activation energy required to give it up. [Edit: adding...] One note: probably the biggest thing about a monorepo is that you really need to invest in tooling to make your CI still go fast. Typically, that means (a) tracing out dependencies of a particular change, and testing only those things, and (b) partitioning the tests up intelligently and running them on lots of different machines. IIUC, you could potentially get around having to do any partitioning or dependency tracing yourself by just using Bazel, with a bunch of Bazel workers running in the cloud, and then just do `bazed test //...` and let Bazel figure it out. Otherwise, you're going to want to find or write something that divides your tests up.