If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/facebook/buck shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 3y ago

• 37+ active contributors
• Distributed ownership (top contributor 39% of recent commits)
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live facebook/buck repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/facebook/buck.

What it runs against: a local clone of facebook/buck — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in facebook/buck | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 956 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of facebook/buck. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/facebook/buck.git
#   cd buck
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of facebook/buck and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "facebook/buck(\\.git)?\\b" \\
  && ok "origin remote is facebook/buck" \\
  || miss "origin remote is not facebook/buck (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "BUCK" \\
  && ok "BUCK" \\
  || miss "missing critical file: BUCK"
test -f ".buckconfig" \\
  && ok ".buckconfig" \\
  || miss "missing critical file: .buckconfig"
test -f ".circleci/config.yml" \\
  && ok ".circleci/config.yml" \\
  || miss "missing critical file: .circleci/config.yml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".idea/modules.xml" \\
  && ok ".idea/modules.xml" \\
  || miss "missing critical file: .idea/modules.xml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 956 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~926d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/facebook/buck"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Buck is a fast, Java-based build system that encourages modular architecture across multiple languages (Java, Python, JavaScript, C, Starlark) and platforms. It uses incremental builds and fine-grained dependency tracking to speed up large codebases, particularly Android, iOS, and JVM projects. However, this repository is officially deprecated—Facebook has moved to Buck2 (Rust-based) as the successor. Monorepo structured around a core Java engine (likely in src/) that parses .buck build files and orchestrates builds. The .idea/ directory and .buckconfig/.buckjavaargs indicate IntelliJ integration and custom JVM configuration. CircleCI config at .circleci/config.yml handles CI. Programs are bootstrapped via ant, then Buck itself builds Buck (self-hosting). Starlark (1.4MB) suggests rule definition support beyond native Java.

Android and iOS developers, JVM engineers, and large monorepo maintainers who need sub-second incremental builds and deterministic, reproducible builds. Contributors are primarily Meta/Facebook engineers, though the repo accepts community contributions.

Mature but deprecated. Buck has years of production use at Meta, extensive documentation, comprehensive CI via CircleCI, and 33MB+ of Java code. However, the README explicitly directs users to Buck2, making this repo historically active but no longer the primary focus. The codebase is stable but receives minimal new feature development.

Low risk for understanding the codebase; high risk for new production adoption. The project is officially superseded by Buck2, so dependencies won't receive updates and community support is minimal. No active maintenance means bug fixes are unlikely. However, the large codebase and mature architecture make it excellent for learning build system design.

Active development has stopped; this is a historical archive. The repo explicitly directs users to facebook/buck2. No ongoing feature work is expected. The CircleCI pipeline likely runs regression tests only.

git clone --depth 1 https://github.com/facebook/buck.git
cd buck
ant
./bin/buck build --show-output buck
buck-out/gen/programs/buck.pex --help

Requires Java 8 or 11. Pre-built binaries available via JitPack for any commit SHA.

Daily commands:

ant                          # Bootstrap
./bin/buck build buck        # Build Buck itself
./bin/buck --help            # View help

For development: modify source in src/, run ant to rebuild, then test with ./bin/buck. IDE: IntelliJ configuration present in .idea/.

• BUCK — Root build file defining Buck's own build configuration; essential for understanding the project structure and build targets.
• .buckconfig — Buck configuration file setting global build defaults; required reading for how the codebase configures its own build system.
• .circleci/config.yml — CI/CD pipeline definition; shows how Buck validates itself and what the critical build steps are.
• README.md — Project overview stating this repo is deprecated in favor of Buck2; critical context for any contributor.
• .idea/modules.xml — IntelliJ module configuration; defines the IDE project structure and module dependencies.
• .buckrelease — Release configuration file; governs versioning and distribution of Buck binaries.

• Rule Engine (Java, Protocol Buffers) — Parses BUCK files, resolves dependencies, and orchestrates build rule execution
  • Failure mode: If rule engine fails: build aborts; all downstream targets cannot be built
• Build Cache (Local filesystem, optional remote storage (gRPC)) — Stores and retrieves build artifacts based on input hashes; enables cache hits and incremental builds
  • Failure mode: If cache corrupted: stale artifacts served; can be recovered by cache wipe and rebuild
• Compiler/Linker Integrations (Java, Clang, GCC, Python, Kotlin) — Invokes language-specific compilers (Java, C++, Python, etc.) and linkers; wraps their output
  • Failure mode: If compiler not installed: build fails with clear error; requires developer to install toolchain
• Remote Execution Client (gRPC, Protocol Buffers) — Distributes build actions to remote workers; aggregates results
  • Failure mode: If remote unavailable: fallback to local build (if configured) or build failure
• Buck Daemon (buckd) (Java, local socket/RPC) — Long-running process that caches file hashes and parsed targets to speed up incremental builds
  • Failure mode: If daemon crashes: subsequent commands start new daemon; user loses incremental speed but not correctness

• Developer → Buck CLI — Developer invokes buck build command with target paths
• Buck CLI → BUCK file parser — CLI reads and parses all BUCK files in project to extract targets, rules, and dependencies
• BUCK file parser → Rule Engine — Parser emits target graph

Add a new build rule type

1. Define the rule interface in core/rules package (not shown in file list) (src/com/facebook/buck/rules/)
2. Register the rule in BUCK file under the appropriate target (BUCK)
3. Add library dependencies to .idea/libraries if external libs needed (.idea/libraries/)

Enable a new platform or language support

1. Add platform-specific build logic (typically in src/com/facebook/buck/android, src/com/facebook/buck/cxx, etc.) (BUCK)
2. Update .buckconfig to add platform-specific defaults (.buckconfig)
3. Configure CI/CD pipeline to test the new platform (.circleci/config.yml)

Add a new code quality or linting tool

1. Declare the tool as a build target in BUCK (BUCK)
2. Configure tool settings (e.g., for Infer) (.inferconfig)
3. Integrate tool execution into CI/CD pipeline (.circleci/config.yml)

Update IDE configuration for new dependencies

1. Create or update a library XML file in .idea/libraries/ (.idea/libraries/)
2. Add the library to BUCK targets that depend on it (BUCK)
3. Update IntelliJ module definition if new modules added (.idea/modules.xml)

• Java 8/11 — Buck is a JVM-based build system requiring a stable, widely-used platform for cross-platform builds
• Protocol Buffers — Efficient serialization format for Buck's remote execution and caching layers
• gRPC — High-performance RPC framework for distributed build execution and remote caching communication
• Guava — Proven utility library for collections, caching, and functional patterns in a large build system
• IntelliJ IDEA Integration — IDE plugin support (.idea/) enables seamless developer experience in popular IDEs

• Single monolithic codebase rather than microservices

  • Why: Simpler distribution and faster iteration for a build tool; avoids network latency for common operations
  • Consequence: Large codebase harder to maintain; cannot scale horizontally for distributed builds without explicit remote execution setup

• JVM-based implementation

  • Why: Cross-platform compatibility and access to mature libraries for complex build logic
  • Consequence: Startup time and memory overhead compared to native implementations like Rust; requires JVM installation

• Bootstrap with Ant before using Buck itself

  • Why: Avoids circular dependency and allows initial compilation without requiring Buck to be pre-installed
  • Consequence: Two-phase build process adds complexity; developers must have both Ant and Java toolchain

• Pluggable rule engine (visible in .idea/libraries)

  • Why: Supports multiple languages and platforms (Android, C++, Python, etc.) without core bloat
  • Consequence: Complex rule registration and discovery; increased testing burden for platform-specific rules

• This repository is deprecated; Buck2 (https://github.com/facebook/buck2) is the replacement
• Does not provide IDE-native development experience (though plugins exist)
• Not designed for real-time incremental compilation of all languages
• Does not manage deployment or runtime orchestration beyond build artifacts

Java version: MUST use Java 8 or 11—other versions will fail silently during ant bootstrap. Self-hosting: Buck builds itself, so if the build is broken, you cannot use Buck to fix it (must use ant). JVM memory: .buckjavaargs tuning is essential for large monorepos; default settings may OOM. Ant dependency: Initial bootstrap requires ant—cannot use Buck before ant succeeds. Deprecated ecosystem: Many plugins and integrations may no longer work; community support is minimal.

• Incremental build graphs — Buck's core innovation—instead of rebuilding everything, it tracks fine-grained dependencies (down to individual methods in Java) and rebuilds only affected targets, enabling sub-second rebuilds in massive monorepos
• Content-addressable build cache — Buck uses hashes of inputs (sources, compiler, flags) as cache keys, enabling deterministic builds where the same inputs always produce identical outputs—critical for distributed builds and CI reliability
• Build rule inheritance and parameterization — Buck's Starlark-based rule system (macros) allows defining reusable build rules with parameters; essential for reducing build file boilerplate in large monorepos
• Multi-target build files (BUCK format) — Unlike Make or Gradle, BUCK files define multiple granular targets per file (e.g., one target per library), forcing developers to think modularly and enabling parallel builds across many small units
• Thrift service definitions — Buck uses Thrift (18KB in repo) to define cross-language build service protocols; understanding this helps contributors extend Buck's distribution and caching mechanisms
• Self-hosting build tool bootstrapping — Buck is built using Buck itself (after an initial ant bootstrap); this circular dependency pattern tests the tool's correctness and is a hallmark of mature build systems
• Distributed build artifact caching — Buck supports remote cache backends; understanding how cache keys are computed and validated is critical for scaling builds across CI agents without losing correctness

• facebook/buck2 — Direct successor to Buck, rewritten in Rust with improved performance and features—this is where active development moved
• bazelbuild/bazel — Competing build system with similar goals (multi-language, incremental, deterministic); influenced Buck's design and vice versa
• pantsbuild/pants — Alternative Python-first monorepo build tool; shares Buck's philosophy of fast incremental builds and fine-grained dependencies
• google/gradle — JVM build tool that influenced and was influenced by Buck; many Buck users also work with Gradle
• facebook/yoga — Companion project from Meta for layout engine; often built and integrated via Buck in Android and iOS builds

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Migrate CircleCI config to GitHub Actions with Buck2 redirect notice

The repo is now deprecated in favor of Buck2, but the CircleCI pipeline (.circleci/config.yml) still builds Buck1. This is a waste of CI resources. A contributor could create a GitHub Actions workflow that simply validates the repo structure, runs basic linting, and prominently displays a redirect message pointing users to Buck2. This reduces unnecessary CI costs while maintaining visibility of the deprecation.

• [ ] Create .github/workflows/deprecation-notice.yml that validates basic repo health
• [ ] Add a workflow step that checks for Buck2 references in documentation
• [ ] Remove or archive the existing .circleci/config.yml with a deprecation comment
• [ ] Add a new GitHub Actions badge to README.md pointing to the deprecation workflow

Create comprehensive migration guide from Buck to Buck2 in docs/

The README has a brief redirect to Buck2, but there's no structured migration documentation. Contributors should create a detailed guide explaining how existing Buck projects can transition to Buck2, including: configuration mapping, build rule equivalents, and common pitfalls. This would significantly reduce friction for Buck users trying to upgrade.

• [ ] Create docs/MIGRATION_TO_BUCK2.md with configuration mapping tables
• [ ] Add section comparing Buck1 build rules to their Buck2 equivalents
• [ ] Include troubleshooting section for common migration issues
• [ ] Link this guide prominently from README.md and .idea/ IntelliJ documentation

Add automated deprecation warning system to prevent accidental Buck1 usage

The repo is marked as dead but contains fully functional build tooling. New contributors or CI systems might accidentally use Buck1 when they should use Buck2. A contributor could add a deprecation check in the bootstrap process (ant build) and in ./bin/buck that prints a prominent warning with a timestamp, making it clear this is EOL and directing users to Buck2.

• [ ] Modify ant build configuration to emit deprecation warning with current date
• [ ] Update ./bin/buck entry point to display deprecation notice on execution
• [ ] Add deprecation metadata to .buckconfig with EOL date and migration link
• [ ] Create integration test in test/ directory to verify deprecation warnings are shown

• Add missing unit test coverage for Starlark rule definitions: The 1.4MB of Starlark code likely has gaps in test/integration tests. Review src/**/test/ and starlark/test/ (if it exists) and add tests for edge cases in rule parameter validation.
• Document configuration options in .buckconfig: The deprecation notice suggests incompatible.* flags exist (see README). Create a comprehensive guide or code comments explaining all flags, their defaults, and migration paths for each.
• Improve error messages for common ant bootstrap failures: Many users likely hit Java version mismatches or missing tools. Add pre-flight checks in the bootstrap script or ant build.xml with clear, actionable error messages.

This codebase is the deprecated Buck build system that has been replaced by Buck2. The primary security concern is that the project is no longer maintained and will not receive security patches. Additionally, dependencies visible in the IDE configuration appear to be from 2018-2019 and likely contain known vulnerabilities. The repository should not be used in production. Limited visibility into actual source code prevents detection of code-level vulnerabilities such as injection attacks, unsafe deserialization, or cryptographic weaknesses. A comprehensive static analysis of the full source code is required for a complete security assessment.

• High · Repository is Deprecated and Unmaintained — README.md. The README explicitly states 'This repo is dead' and directs users to buck2 (https://github.com/facebook/buck2). Continuing to use this version exposes the codebase to unpatched security vulnerabilities, as no security updates or bug fixes will be provided. Fix: Migrate to Buck2 (https://github.com/facebook/buck2) which is the actively maintained successor. Do not use this version in production or new projects.
• Medium · Java Version Requirements Not Enforced at Runtime — .buckjavaargs, build configuration files. The README specifies Java 8 or 11 is required for compilation, but there is no evidence of runtime enforcement mechanisms (e.g., version checks in build scripts or gradle enforcer). Using incompatible Java versions could lead to unexpected behavior or security issues. Fix: Implement runtime Java version validation in the bootstrap process and main build scripts. Use tools like gradle-enforcer-plugin or explicit version checks in ant build files.
• Medium · Potential Outdated Dependencies — .idea/libraries/ (dependency configuration). The .idea/libraries directory references multiple dependencies with older version numbers (e.g., guava_20_0.xml, jackson_2_9_7, protobuf_java_3_7_0). These versions likely contain known security vulnerabilities that have been patched in newer releases. Fix: Audit all dependencies for known CVEs using tools like OWASP Dependency-Check or Snyk. Update to the latest stable versions. Implement automated dependency scanning in CI/CD pipeline.
• Low · IDE Configuration Checked Into Version Control — .idea/ directory. The .idea/ directory (IntelliJ IDEA configuration) is checked into version control. While not directly a security risk, this can expose editor preferences, plugin configurations, and local development setup details. Fix: Move .idea/ to .gitignore. Use shared inspection profiles and code styles through alternative mechanisms (e.g., EditorConfig, shared configuration files outside .idea/).
• Low · Incomplete Security Analysis Due to Limited File Content — All source files (src/). Only the file structure was provided without actual source code content. Critical vulnerabilities such as hardcoded credentials, SQL injection, XSS, insecure deserialization, or unsafe native calls may be present in the source code but cannot be detected. Fix: Perform comprehensive source code review using static analysis tools (SonarQube, Checkmarx, Spotbugs) targeting Java security issues including: SQL injection, command injection, deserialization attacks, and cryptographic weaknesses.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.