Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Nomenclature

This page defines the terminology used throughout RSConstruct’s code, configuration, CLI, and documentation.

Core concepts

TermDefinition
pnameProcessor name. The type name of a processor as registered by its plugin (e.g., ruff, pip, tera, creator). Unique across all plugins. Used in [processor.PNAME] config sections and in processors defconfig PNAME.
inameInstance name. The name of a specific processor instance as declared in rsconstruct.toml. For single-instance processors, the iname equals the pname (e.g., [processor.ruff] → iname is ruff). For multi-instance processors, the iname is the sub-key (e.g., [processor.creator.venv] → iname is creator.venv). Used in processors config INAME.
processorA configured instance that discovers products and executes builds. Created from a plugin + TOML config. Immutable after creation.
pluginA factory registered at compile time via inventory::submit!. Knows how to create processors from TOML config. Has a pname, a processor type, and config metadata.
productA single build unit with inputs, outputs, and a processor. The atomic unit of incremental building.
processor typeOne of four categories: checker, generator, creator, explicit. Determines how inputs are discovered, how outputs are declared, and how results are cached. See Processor Types.
analyzerA dependency scanner that runs after product discovery to add extra input edges to existing products (e.g., the cpp analyzer adds every #included header as an extra input of a C/C++ product). Analyzers never create products of their own. Declared with [analyzer.NAME] sections in rsconstruct.toml. Unlike processors, only analyzers explicitly declared in config run — there is no “auto-enable” default. See Dependency Analyzers.
analyzer pluginA factory registered at compile time via inventory::submit! in the analyzer registry. Knows how to construct an analyzer from its [analyzer.NAME] TOML section. Each plugin declares its name, description, and whether it is native (pure Rust) or external (may invoke subprocesses).
native analyzerAn analyzer whose default configuration runs entirely in-process (no subprocesses). Example: icpp uses a pure-Rust regex scanner for #include directives. Some native analyzers become external in non-default configurations (e.g., icpp with pkg_config set shells out to pkg-config for include paths).
external analyzerAn analyzer that shells out to another program to do its work. Example: cpp always runs gcc -MM for exact compiler-accurate header scanning.

Configuration

TermDefinition
output_filesList of individual output files declared in creator/explicit config. Cached as blobs.
output_dirsList of output directories declared in creator/explicit config. All files inside are walked and cached as a tree.
src_dirsDirectories to scan for input files.
src_extensionsFile extensions to match during scanning.
dep_inputsExtra files that trigger a rebuild when their content changes.
dep_autoConfig files silently added as dep_inputs when they exist on disk (e.g., .eslintrc).

Cache

TermDefinition
blobA file’s raw content stored in the object store, addressed by SHA-256 hash. Blobs have no path — the consumer knows where to restore them.
treeA serialized list of (path, mode, blob_checksum) entries describing a set of output files. Stored in the descriptor store.
markerA zero-byte descriptor indicating a checker passed. Its presence is the cached result.
descriptorA cache entry (blob reference, tree, or marker) stored in .rsconstruct/descriptors/, keyed by the descriptor key.
descriptor keyA content-addressed hash of (pname, config_hash, variant, input_checksum). Changes when processor config or input content changes. Does NOT include file paths — renaming a file with identical content produces the same key.
input checksumCombined SHA-256 hash of all input file contents for a product.

Build pipeline

TermDefinition
discoverPhase where processors scan the file index and register products in the build graph.
classifyPhase where each product is classified as skip, restore, or build based on its cache state.
executePhase where products are built in dependency order.
anchor fileA file whose presence triggers a creator processor to run (e.g., Cargo.toml for cargo, requirements.txt for pip).

CLI conventions

CommandName parameterMeaning
processors defconfig PNAMEpnameProcessor type name — shows factory defaults
processors config [INAME]inameInstance name from config — shows resolved config
processors files [INAME]inameInstance name from config — shows discovered files
analyzers defconfig [NAME]analyzer nameAnalyzer name from the analyzer registry — shows factory defaults
analyzers config [NAME]analyzer nameAnalyzer name as declared in [analyzer.NAME] — shows resolved config