Bazel Build and Test Tool

Bazel is an open-source tool that automates software builds and tests. It is designed for large-scale, multi-language, and multi-platform projects.

Key features include:

• Multi-language support: Supports many languages out-of-the-box and is extensible to arbitrary languages.
• High-level build language: Uses BUILD files to describe projects as sets of interconnected libraries, binaries, and tests, rather than individual file/compiler invocations.
• Multi-platform support: The same BUILD files can target different architectures and platforms (e.g., server applications and mobile apps).
• Reproducibility: Requires complete specification of direct dependencies, ensuring incremental builds are deterministic and produce the same result every time.
• Scalability: Optimized for massive codebases where builds can be highly parallelized and incremental changes can be processed extremely quickly.

Bazel is used across diverse industries and technology stacks to solve common build challenges. Key patterns observed in large-scale deployments include:

• Monorepo Management: Companies like JetBrains, Uber, and Lyft use Bazel to manage massive monorepos containing multiple languages (Go, Java, C++, Scala, etc.).
• Mobile Development: Extensive use for iOS and Android apps (LinkedIn, Lyft, Pinterest, Spotify, Tinder, Tokopedia) to achieve faster, more reliable, and hermetic builds.
• Backend Services: Used for compiling polyglot backend services (Stripe, Ritual, Tink, Redfin) often leveraging remote caching and remote execution.
• Embedded Systems: Used for reliable builds in safety-critical automotive and embedded environments (Peloton, Pigweed).
• Performance Optimization: Many users (Line, Lucid Software, Redfin, Tokopedia, Wix) report significant reductions in build times (often 5x to 10x faster) by utilizing Bazel's aggressive caching and parallelism.
• Remote Execution & Caching: Large organizations (Wix, Jupiter) utilize remote execution and caching to scale build/test parallelism and reduce local resource requirements.

Bazel has a variety of product partners providing specialized tooling for build acceleration, observability, and CI/CD integration. Key categories include:

• Build Acceleration & Remote Execution: Tools like Aspect Build, BuildBuddy, EngFlow, Nativelink, and Bitrise provide remote execution, shared build caches, and optimized CI workflows to reduce build times and costs.
• Observability & Analytics: Develocity (by Gradle Inc.) and BuildBuddy offer build scans, failure analytics, and UI-based debugging for build and test results.
• CI/CD Platforms: Bitrise (mobile-first), Buildkite (scale-out delivery), and Aspect Workflows provide deep Bazel integration for continuous integration and delivery.
• Consulting & Migration: VirtusLab and Tweag specialize in monorepo management, codebase migration to Bazel, and achieving build reproducibility.
• Visualization: Tweag provides Skyscope to visualize complex Bazel build graphs in a web browser.

In large repositories, common patterns like transitive property computation (e.g., Java classpaths) or multiple binaries depending on the same library rules can lead to $O(N^2)$ memory and time consumption if standard collections (like lists) are used.

To prevent this, Bazel provides a specialized collection type called depset (internally known as NestedSet).

Best Practices for depset:

• Use depset for transitive collections: Use it instead of lists or sets when aggregating properties across a dependency graph (e.g., link commands, classpaths).
• Avoid repeated iteration: Even when using a depset, iterating over it inside every rule in a chain can re-introduce $O(N^2)$ time complexity.
• Avoid interoperability helpers: Be careful when passing a depset to helper methods designed for standard collection classes, as these often trigger a full copy of the data, re-introducing quadratic memory consumption.

# Example concept: using a depset for transitive dependencies
# (Note: Actual API usage depends on the specific rule context)
my_depset = depset(transitive = [other_depset])

Bazel uses Skyframe, a graph evaluation framework, to track dependencies and ensure incremental builds. To ensure Skyframe can correctly track what a rule depends on, you must follow these constraints:

1. Use the Rules API for dependency discovery: Do not bypass the framework. All accesses to other nodes (files, packages, or other rules) must go through the provided Bazel APIs so the dependency graph can be built.
2. Avoid standard libraries that bypass Skyframe: In rule implementations (especially if using Java), avoid using java.io.File, reflection, or any third-party libraries that perform direct file I/O or reflection. These bypass Skyframe's tracking and lead to incorrect builds.
3. Prefer bulk dependency declaration: Because Bazel uses a fixed-size thread pool, declaring dependencies serially (one after another) can cause a node to be restarted multiple times, leading to $O(N^2)$ time complexity. Aim to declare dependencies in bulk up-front to minimize restarts.

When working with Android Interface Definition Language (AIDL) files, you must ensure the AIDL compiler can find the files based on their package declarations.

• idl_import_root: Use this to specify a package-relative path to the root of the Java package tree containing your IDL sources. This is necessary if your .aidl files are not located directly under a standard Java root (e.g., they are in a src/ subdirectory).
• idl_parcelables: Use this for .aidl files that correspond to custom Parcelable implementations. These are provided as imports to dependers but are not compiled into Java interfaces.
• idl_srcs: Use this for .aidl files that need to be translated into Java interfaces. These interfaces will be compiled along with your srcs.
• idl_preprocessed: Use this for preprocessed .aidl definitions that should be provided as imports without being translated or compiled.

android_library(
    name = "foreign_interface",
    idl_srcs = [
        "src/android/helloandroid/OtherInterface.aidl",
        "src/android/helloandroid/CallbackInterface.aidl"
    ],
    # Setting idl_import_root to "src" allows the compiler to find 
    # android.helloandroid.CallbackInterface at src/android/helloandroid/CallbackInterface.aidl
    idl_import_root = "src",
)