Blade Build System: automatic transitive dependency resolution for polyglot monorepos

Blade resolves transitive library dependencies so callers only declare what they directly use

The design principle Blade is built around is that a BUILD file should track only direct dependencies. When the foo library depends on common, that relationship belongs in foo's BUILD file, not in the BUILD file of every binary that happens to link through foo. Two BUILD rules in the README make this explicit:

cc_library(
    name = 'foo',
    srcs = ...,
    hdrs = ...,
    deps = ':common'
)

cc_binary(
    name = 'my_app',
    srcs = ...,
    deps = ':foo'
)

Blade traces the dependency chain from my_app back through foo and on to common, deciding at build time which objects need to be recompiled before the link step. In large codebases, library implementations change frequently, and any build system requiring every caller to maintain the full transitive dependency tree produces coordination overhead that grows with project size. Blade keeps that tracking inside the tool itself, so the program's BUILD file stays limited to what the program's authors directly control.

This system originated at Tencent in 2010, when the Typhoon cloud computing platform grew large enough that GNU Make and Autotools no longer served the team's workflow. Google's engineering blog posts from August 2011 on build system architecture informed the design. The README points to a Tencent Ads engineering post about operating a 30-million-line codebase at that scale, with Blade serving as the build layer for that workflow.

The BUILD format natively covers C/C++, Java, Python, Scala, Protocol Buffers, lex, yacc, and SWIG in one syntax

All supported languages share one BUILD file syntax, so a project mixing C++ libraries with Protocol Buffer definitions and a Python test harness does not need a separate make fragment for each language boundary. Lex, yacc, and SWIG all produce outputs that other targets consume, and Blade sequences those code-generation steps automatically once the dependencies are declared.

The supported language list is specific: C/C++, Java, Python, Scala, Protocol Buffers, lex, yacc, and SWIG. Go, Rust, and TypeScript do not appear in it. Projects needing those either wrap them in a custom build rule or manage them outside Blade. Custom rules are supported, but writing one requires adding Python code to the repository.

In the C/C++ path, when a header file changes, Blade determines which translation units included it and schedules those for recompilation, without requiring the programmer to declare or maintain a separate header list. Stale header dependency records in Make-based C++ builds cause silent missed recompilations that surface only when a clean build is run. Blade's scanner replaces that manual tracking.

Different gcc and clang versions can be chosen as the active compiler for a given build invocation without editing BUILD files. Multi-platform targets are a named variant as well, enabling the same BUILD files to produce artifacts for several architectures in one run.

Blade ships an install script at the repository root and requires Python 3.10 before any build can run

Since Blade runs as a Python package, there is no binary to build before the first use. Python 3.10 is the minimum version, as stated in the README's Python badge. The repository root contains a file named `install` for Unix-like systems and a `setup.bat` for Windows. The README does not reproduce install commands in the section available here; the documentation at blade-build.github.io carries the full setup procedure.

After setup, the tool uses a subcommand interface where the operation name comes immediately after the binary, in a format similar to git. Three test invocations in the README demonstrate the pattern. Recursively testing all targets under a directory named common:

blade test common...

Testing in debug mode:

blade test -pdebug common...

Testing with the address sanitizer:

blade test --sanitizer=address common...

The trailing three dots are Blade's recursive target syntax, applying the subcommand to the named directory and every target beneath it. Invoking blade from inside a component's subdirectory limits the scope to that subtree without navigating to the repository root first, which is useful when only one team's code is under active change.

Shell completion for bash commands is available after install. A VS Code extension with the marketplace identifier `blade-build.vscode-blade` brings a targets explorer and BUILD-file language features into the editor. A syntax file for BUILD scripts is included under `vim/` in the repository, for editors that load Vim plugins.

vcpkg integration in v3.x turns a C/C++ third-party library into a single deps field entry

Before vcpkg matured, the README describes using third-party C/C++ libraries in Blade as cumbersome. With vcpkg integrated directly as the package manager for C/C++ dependencies, a vcpkg port is declared in the `deps` field using the syntax `vcpkg#<port>:<lib>`, and Blade handles installation and linking from there.

Two features accompany the integration: version pinning and a binary cache. Version pinning ensures the same package version is installed on every machine that builds the project, closing the gap where two developers build with different library versions and produce subtly different binaries. The binary cache avoids rebuilding the same library on each clean checkout, a practical concern for CI environments that start fresh on every run.

Documentation for vcpkg usage is at `doc/en/build_rules/vcpkg.md` in the repository, which the README points to explicitly for port syntax, version lock format, and cache configuration. Java, Python, Scala, and Protobuf targets each manage their external dependencies through their own toolchain conventions, not through vcpkg.

Incremental and parallel testing are built into blade test, with gperftools available for memory-leak detection

Blade does not treat testing as a separate step outside the build. The `blade test` subcommand handles the full build-then-test cycle without a separate testing command. A test binary that passed last time and whose code and inputs are unchanged is not executed again on the next run, which shortens repeated test cycles in directories with many targets. Test executables sharing no code dependencies run at the same time, so wall-clock time scales with available cores rather than test count.

For memory errors, two mechanisms are described in the README. Gperftools detects memory leaks in test binaries through Blade's integration, with no detection calls required in test code. The address sanitizer, enabled with `--sanitizer=address` on a test invocation, surfaces memory errors during the run rather than waiting for a production failure.

Ccache and distcc are both documented as supported options and neither requires changes to BUILD files; both depend on environment-level configuration rather than build-rule changes. The README gives no configuration steps for either, so each tool's own documentation is the next reference for teams that need them.

Linux is the primary documented environment; Windows and macOS differ in compiler chain and supported architectures

The README states that Linux, macOS, and Windows are all supported platforms, but the documented setup for each differs. Linux is listed with three processor architectures: i386, x86_64, and aarch64. macOS is paired with clang as the compiler. Windows support uses MSVC. Separate CI workflows for all three platforms confirm that cross-platform testing is part of the project's release process.

For a team building entirely on Linux, those differences create no friction. For a project requiring identical artifacts on all three platforms, the compiler differences introduce separate sets of warnings, different sanitizer coverage levels, and platform-specific ABI details the README does not document. There is no section covering known behavioral differences by platform or listing which sanitizer flags work under MSVC.

The ccache and distcc features appear in the supported-features list without platform qualifications, but the README gives no guidance on how either behaves on Windows with MSVC. Any team that uses those features on Windows needs to verify behavior against their own environment before building CI pipelines around them.

The NewBSD licence in COPYING, three releases in one month, and the Python version floor

GitHub classifies the licence as Other because it cannot match it automatically to a known SPDX identifier, but the README badge labels it NewBSD. NewBSD, also called the 3-Clause BSD licence, permits use, modification, and redistribution with attribution. The COPYING file in the repository is the authoritative text, and it is the document to read before redistributing a modified copy.

Release pace between June and July 2026 was unusually compressed: v3.0.0 was released on 2026-06-27, v3.0.1 followed on 2026-07-01, and v3.1.0 arrived on 2026-07-26. Three releases in one month signals either a burst of planned work or rapid iteration on newly shipped functionality. The last push was on 2026-08-13, and the repository is not archived.

Blade being written in Python creates a direct dependency on the Python version in the build environment. Python 3.10 is the documented floor, so teams that pin their Python version to an older release need to account for that constraint before adopting Blade. Any upgrade to the Python installation used for builds also affects Blade's runtime behavior directly, since the build tool executes in that interpreter on every invocation.

Editorial conclusion

Blade suits teams running large C++ monorepos on Linux who want automatic header scanning, transitive dependency tracking, and built-in incremental testing without a separate test harness. Python 3.10 is required before Blade itself can be used. Before committing, verify that every language you need is on the supported list, read the COPYING file for the NewBSD licence terms, and test vcpkg integration against your specific ports for any third-party C/C++ libraries the project uses. Skip it when your build already works cleanly with Make, or when you need commercial support contracts the repository does not document.

Frequently asked questions

Official sources

1. blade-build/blade-build on GitHub
2. Issues
3. Project website
4. README
5. Releases