Buck2 Documentation

website·Indexed Apr 12, 2026

https://buck2.build/docs/

Official documentation for Buck2, a large-scale, fast, and extensible build tool developed by Meta and written in Rust. The docs cover bootstrapping, language ecosystem support (C/C++, Java, Python, Rust, etc.), and the Starlark-based API for rule writers and integrators. Includes detailed references for build APIs, providers like DefaultInfo and ConfigurationInfo, and error handling contexts.

Tokens
35.9K
Snippets
68
Records
411
Agent score
50%

What's inside Buck2

  1. cxx_python_extension rule overview

    The cxx_python_extension() rule builds a Python module from a single .cpp file. It functions as a C/C++ library variant where the module name is derived from the base_module parameter and the rule name. The resulting binary is a Python extension that can be imported directly into Python code.
  2. ConfiguredAttr class overview

    ConfiguredAttr provides methods for accessing attributes on a configured target node in Buck2 BXL scripts. It offers three main capabilities: stripping configuration strings, retrieving the attribute type name, and accessing the unresolved attribute value.
  3. Buck-out directory purpose and characteristics

    Buck-out is Buck2's output directory where build artifacts, test outputs, logs, and temporary data are stored. Key characteristics: (1) Located under the repository root, (2) Uses a hashed directory structure for caching purposes, (3) Stores output artifacts, Buck log files, and tmp data, (4) Managed entirely by Buck—developers should not manipulate its contents. Output artifacts cannot be stored in the source directory (which is version-controlled) and must be cached for reuse to save build time.
  4. ProvidersLabel class overview

    ProvidersLabel exposes attributes and methods for accessing label components such as cell, name, package, and package_path. It provides direct access to the raw target label via the raw_target method and defines the sub_target attribute as an optional list of strings.
  5. Build rules, targets, and files in Buck2

    A build rule describes how to produce an output file from input files. Build rules are language or platform-specific (e.g., cxx_binary for C++ binaries, android_binary for Android APKs). A build target is a string that uniquely identifies a build rule, functioning like a URI within the project. Build files (typically named BUCK) define one or more build rules and are analogous to Makefiles. Each buildable unit (binary or library) usually has its own BUCK file.
  6. TransitiveSet class overview

    Represents a transitive set in Buck2 for managing hierarchical data. Provides methods to project data as arguments or JSON, reduce sets, and traverse elements with configurable ordering. The children property returns child elements, definition provides the set definition, and value holds the underlying data.
  7. Adopt Bazel's Build Event Protocol for Buck2 OSS observability

    The RFC proposes adopting Bazel's Build Event Protocol (BEP) for Buck2 OSS observability instead of creating a custom protocol or using OpenTelemetry/Prometheus. BEP is preferred because: it is tool-agnostic, has existing tooling support (BuildBuddy, EngFlow, Buildb.io), shares similarities with Bazel that benefit adoption, and distributes development/maintenance burden across contributors. Buck2's existing BuckEvent can be transformed into BEP-compatible format.
  8. ConstraintSettingInfo provider type

    Provider returned by a constraint_setting() target to signal that a target can be used as a constraint key. This is the only provider returned by constraint_setting targets.
  9. BXL extension language overview

    BXL is a Starlark-based script that enables integrators to inspect and interact with the Buck2 build graph. It allows writing Starlark code that queries, analyzes, and builds on the graph, with native introspection of graph structures in a safe, controlled manner. BXL supports introspection at unconfigured, configured, providers, and action stages. Key features include incremental caching, running actions, dynamic outputs, anonymous targets, profiling, and custom telemetry. BXL is considered mostly stable.
  10. Bxl Actions API Overview

    The Bxl Actions API mirrors the rules' actions API exactly. It provides the same ctx.actions interface for registering artifacts, creating actions, and using dynamic actions. This allows integrators to write Starlark snippets that introspect the Buck2 graph and perform operations within Starlark.
  11. android_instrumentation_apk rule overview

    The android_instrumentation_apk() rule generates an Android Instrumentation APK for testing. It corresponds to a test package in Android's testing model. A critical constraint: test packages are compiled against an application package but must NOT include the resources or Java classes of that application package. The rule automatically excludes these to prevent mysterious runtime errors. Building produces a file named {name}_test.apk.
  12. sh_test rule overview and platform support

    The sh_test() rule is a test rule in Buck2 that invokes shell scripts to pass results to the test runner. The script must be executable. This rule is not currently supported on Windows.