Buck2 is a fast, hermetic, multi-language build system, and a direct successor to the original Buck build system (“Buck1”) — both designed by Meta.

But what do those words really mean for a build system — and why might they interest you? “But why Buck2?” you might ask, when so many build systems already exist?

• Fast. It doesn’t matter whether a single build command takes 60 seconds to complete, or 0.1 seconds: when you have to build things, Buck2 doesn’t waste time — it calculates the critical path and gets out of the way, with minimal overhead. It’s not just the core design, but also careful attention to detail that makes Buck2 so snappy. Buck2 is up to 2x faster than Buck1 in practice[^perf-note]. So you spend more time iterating, and less time waiting.
• Hermetic. When using Remote Execution[^hermetic-re-only], Buck2 becomes hermetic: it is required for a build rule to correctly declare all of its inputs; if they aren’t specified correctly (e.g. a .c file needs a .h file that isn’t correctly specified), the build will fail. This enforced correctness helps avoids entire classes of errors that most build systems allow, and helps ensure builds work everywhere for all users. And Buck2 correctly tracks dependencies with far better accuracy than Buck1, in more languages, across more scenarios. That means “it compiles on my machine” can become a thing of the past.
• Multi-language. Many teams have to deal with multiple programming languages that have complex inter-dependencies, and struggle to express that. Most people settle with make and tie together dune to pip and cargo. But then how do you run test suites, code coverage, or query code databases? Buck2 is designed to support multiple languages from the start, with abstractions for interoperation. And because it’s completely scriptable, and users can implement language support — it’s incredibly flexible. Now your Python library can depend on an OCaml library, and your OCaml library can depend on a Rust crate — and with a single build tool, you have a consistent UX to build and test and integrate all of these components.

[^perf-note]: This number comes from internal usage of Buck1 versus Buck2 at Meta. Please note that appropriate comparisons with systems like Bazel have yet to be performed; Buck1 is the baseline because it’s simply what existed and what had to be replaced. Please benchmark Buck2 against your favorite tools and let us know how it goes!

[^hermetic-re-only]: Buck2 currently does not sandbox local-only build steps; in contrast, Buck2 using Remote Execution is always hermetic by design. The vast majority of build rules are remote compatible, as well. Despite that, we hope to lift this restriction in the (hopefully short-term) future so that local-only builds are hermetic as well.

If you’re familiar with systems like Buck1, Bazel, or Pants — then Buck2 will feel warm and cozy, and these ideas will be familiar. But then why create Buck2 if those already exist? Because that isn’t all — the page “Why Buck2?” on our website goes into more detail on several other important design criteria that separate Buck2 from the rest of the pack, including:

• Support for ultra-large repositories, through filesystem virtualization and watching for changes to the filesystem.
• Totally language-agnostic core executable, with a small API — even C/C++ support is written as a library. You can write everything from scratch, if you wanted.
• “Buck Extension Language” (BXL) can be used for self-introspection of the build system, allowing automation tools to inspect and run actions in the build graph. This allows you to more cleanly support features that need graph introspection, like LSPs or compilation databases.
• Support for distributed compilation, using the same Remote Execution API that is supported by Bazel. Existing solutions like BuildBarn, BuildBuddy, EngFlow, and NativeLink all work today.
• An efficient, robust, and sound design — inspired by modern theory of build systems and incremental computation.
• And more!

If these headline features make you interested — check out the Getting Started guide!

🚧🚧🚧 Warning 🚧🚧🚧 — rough terrain lies ahead

Buck2 currently does not have a stable release tag at this time. Pre-release tags/binaries, and stable tags/binaries, will come at later dates. Despite that, it is used extensively inside of Meta on vast amounts of code every day, and buck2-prelude is the same code used internally for all these builds, as well. (However, Meta retains large amounts of Starlark code which builds on top of the prelude.)

Meta just uses the latest committed HEAD version of Buck2 at all times. Your mileage may vary — but at the moment, tracking HEAD is ideal for submitting bug reports and catching regressions.

The short of this is that you should consider this project and its code to be battle-tested and working, but outside consumers will encounter quite a lot of rough edges right now — several features are missing or in progress, some toolchains from Buck1 are missing, and you’ll probably have to fiddle with things more than necessary to get it nice and polished.

Please provide feedback by submitting issues and questions!

Installing Buck2

You can get started by downloading a bi-monthly version or the latest built binary for your platform. The latest tag always refers to a recent commit; it is updated on every single push to the GitHub repository, so it will always be a recent version.

Alternately, you can use dotslash with the bi-monthly releases where it’s easy to deploy into a repo with a single text file and auto pull the correct platform as needed.

You can also compile Buck2 from source, if a binary isn’t immediately available for your use; check out the docs for information.

Terminology conventions

Frequently used terms and their definitions can be found on the glossary page.

License

Buck2 is licensed under both the MIT license and Apache-2.0 license; the exact terms can be found in the LICENSE-MIT and LICENSE-APACHE files, respectively.