Building and Installing

ripgrep is a recursive, line-oriented regular-expression search tool whose default behavior includes respecting ignore files and skipping hidden and binary files. This page focuses on the repository-side build behavior: compile-time metadata, platform linker settings, generated interface artifacts, and optional PCRE2 support.

The supplied excerpts do not show a repository build command or a minimum supported Rust version, so those details cannot be named here without guessing. The visible installation material instead documents precompiled archives and identifies the executable as rg.

Sources: README.md:1-8, build.rs:1-4, build.rs:12-32, crates/core/flags/mod.rs:1-10, README.md:233-240

Core concepts

Build script

A build script is compile-time Rust code that prepares metadata or linker arguments before the binary is produced; this repository implements it in build.rs through main, set_git_revision_hash, and set_windows_exe_options.

Sources: build.rs:1-4, build.rs:12-32, build.rs:36-61

Generated interface

A generated interface is output derived from the command-line flag definitions, including the man page and shell completions; the flags module owns this responsibility rather than the visible build.rs logic.

Sources: crates/core/flags/mod.rs:1-10, crates/core/flags/lowargs.rs:228-241

Cargo feature

A Cargo feature is a build-time switch that changes which capabilities are compiled, and the visible pcre2 feature controls whether PCRE2 matching is available.

Sources: crates/core/flags/doc/version.rs:160-167, crates/core/flags/hiargs.rs:415-422

Static linking

Static linking places required runtime or system components into the executable instead of requiring a separate runtime DLL or dynamically linked system library; the repository configures this for selected Windows MSVC and MUSL targets.

Sources: .cargo/config.toml:1-20

What happens during a build

The build script’s entry point runs two independent preparation steps: it embeds a short Git revision when possible and applies Windows-specific executable options when the target requires them.

fn main() {
    set_git_revision_hash();
    set_windows_exe_options();
}

The important boundary is that main coordinates compile-time setup; it does not itself generate the man page or shell completion files in the shown code.

The following table separates the visible build-script responsibilities.

set_git_revision_hash runs git rev-parse --short=10 HEAD, trims the output, and emits RIPGREP_BUILD_GIT_HASH when the result is non-empty. If Git cannot run or returns an empty revision, the build emits a Cargo warning and skips embedding the hash rather than treating the missing hash as a fatal error. That metadata is useful because verbose version output may include the Git revision and other build information.

The Windows path is deliberately conditional: set_windows_exe_options returns unless both CARGO_CFG_TARGET_OS is windows and CARGO_CFG_TARGET_ENV is msvc. For a matching target, it resolves pkg/windows/Manifest.xml, asks Cargo to rerun when that file changes, embeds the manifest into the rg executable, and turns linker warnings into errors.

This workflow shows the compile-time order and the platform-specific branch.

Sources: build.rs:1-4, crates/core/flags/mod.rs:1-10, build.rs:12-32, build.rs:13, build.rs:36-61, crates/core/flags/defs.rs:7687-7692

How generated docs and completions are produced

The command-line flag module defines flags, parses and validates them, and also generates shell completions, --help output, and the man page. The GenerateMode enum names the supported generated outputs: man, Bash, Zsh, Fish, and PowerShell completions. The visible Zsh completion definitions also expose the --generate choices for these artifacts.

This means changing flag definitions can affect generated documentation and completion behavior because those outputs are derived from the same flag model. The Bash generator exposes a generate function, while the PowerShell generator does the same for its shell. Zsh is an exception in maintenance style: its completion file is maintained by hand, and CI checks that new flags are represented there.

The call order for the build script is separate from this generation path: main calls only set_git_revision_hash and set_windows_exe_options, while the flags module owns generation.

Sources: crates/core/flags/mod.rs:1-10, crates/core/flags/lowargs.rs:228-241, crates/core/flags/complete/rg.zsh:321-327, crates/core/flags/complete/bash.rs:59-63, crates/core/flags/complete/powershell.rs:39-45, crates/core/flags/complete/zsh.rs:1-17, build.rs:1-4

Producing static binaries with PCRE2

For a statically linked MUSL build, the visible Cargo configuration targets x86_64-unknown-linux-musl, enables +crt-static, and requests link-self-contained=yes. The configuration explains that MUSL is intended to produce a fully statically linked executable. Windows MSVC targets x86_64-pc-windows-msvc and i686-pc-windows-msvc likewise receive +crt-static, so the resulting EXE does not depend on the vcruntime DLL.

PCRE2 is a separate concern from static linking. The pcre2 feature is reported in version information as enabled or disabled, and matcher_pcre2 returns an error when that feature is absent. When PCRE2 is available, the --pcre2 flag selects it, and the --pcre2-version behavior reports the library version or an error if support was not compiled in.

Therefore, the evidence supports this build shape: choose the MUSL target for static-linking settings, and enable the pcre2 Cargo feature for PCRE2 support. The excerpts do not provide the exact Cargo command or dependency installation steps, so those command-line details are intentionally not specified here.

Sources: .cargo/config.toml:10-20, .cargo/config.toml:10-15, .cargo/config.toml:1-8, crates/core/flags/doc/version.rs:160-167, crates/core/flags/hiargs.rs:415-422, crates/core/flags/hiargs.rs:460-465, crates/core/flags/complete/rg.zsh:231-237, crates/core/flags/defs.rs:5786-5807

How it connects

• For the overall purpose and codebase shape, continue to Project Overview.
• For the workspace and crate boundaries affected by compilation, see Repository and Crate Map.
• For generated man pages, shell completions, and packaging manifests, see Packaging, Completions, and Docs Generation.
• For release checks and published binaries, see CI and Release Pipeline.
• For PCRE2’s runtime matcher behavior, see The PCRE2 Matcher.

Sources: README.md:1-8, crates/core/flags/mod.rs:1-10, crates/core/flags/lowargs.rs:228-241, README.md:233-240, crates/core/flags/hiargs.rs:415-422

Key takeaways

• build.rs embeds a Git revision when available and applies Windows MSVC linker options conditionally.
• The flags module, not the visible build script, owns man-page and shell-completion generation.
• MUSL configuration enables static linking for x86_64-unknown-linux-musl.
• PCRE2 requires the pcre2 feature; static linking and PCRE2 support are separate build concerns.
• The supplied excerpts do not establish the exact build command or minimum supported Rust version.