The.make recipe reference

Hypermake's recipe language keeps Make's rule anatomy — target: prerequisites plus tab-indented commands — and drops the macro language. Graph facts live in rule headers; behavior lives in commands; discovery lives in dedicated producer targets. Every rule on this page is real: the first two build the page you are reading.

Rule anatomy

A recipe is a path-local .make file: the file sits at the path that explains its target (src://rendered/public/{path}.html.make owns rendered/public/{path}.html). This site's page recipe:

rendered/public/{path}.html: rendered/public/{path}.html.d | rendered/public/{path|dirname}/
	lzr render-page --root {rootQ} --in src/{path}.html --template {path}.html --components-config config.json --components src/_components --out "$@" --minify
		

• The rule header is one line: target: prerequisites, with a space after the colon (a:b is an invalid header). Bare target: declares no prerequisites. Backslash line continuations are not supported — the header stays on one line.
• One target per header. A header like a b: c does not create two targets; it creates one unbuildable target named "a b". One artifact, one rule.
• Command lines are tab-indented and run through bash from the project root. A rule with no command lines is a parse error — the whole file is rejected and hypermake doctor reports recipe.parse_failed.
• A blank line ends the rule. # comment lines are skipped anywhere, including between commands.
• GNU command prefixes are accepted: - ignores a failing command; @ and + are stripped.
• Prerequisites after | are order-only: they gate existence without forcing rebuilds, and order-only directories (trailing /) are created before the commands run.

Named captures, not %

Patterns use named captures such as {path} or {asset}. GNU's % is not a wildcard here — it matches literally, and the linter says so. The captured name binds everywhere in the rule: prerequisites, order-only entries, and commands.

rendered/public/assets/{asset}.css: src/assets/{asset}.css | rendered/public/assets/
	cp "$<" "$@"
		

The target's own captures select the source: adding src/assets/print.css publishes rendered/public/assets/print.css with no new rule. Some capture names are typed:

A capture repeated in one pattern must bind the same text each time. When several recipes match one target, the highest specificity score wins: literal characters and typed captures raise it, captures lower it — so a colocated literal recipe usually specializes a broad pattern, but specificity is computed, never assumed. hypermake match TARGET --json discloses the chosen recipe, its score, and the bound captures; two recipes producing the same target shape at equal precedence are a hard load error ("declares duplicate target family").

Prerequisites are matcher surfaces

A prerequisite is not just a file that already exists — it declares where change can come from. Three shapes, one doctrine:

static           src/site.css
target-derived   src/assets/{asset}.css
discovery        src/**/*.css
		

A prerequisite containing glob characters (*, ?, [...], recursive **) becomes a discovery matcher: it is fingerprinted in target state as hypermake-matcher://src/**/*.css — the matched file list plus each file's fingerprint — rather than a concrete edge. A newly created file that matches the glob invalidates the target, so the graph notices files that did not exist when the rule was written. Matcher prerequisites are not passed to $< or $^.

Automatic and template variables

Target flags

Non-file semantics are declared per target, above the rule they modify, in the same file:

.VIRTUAL: cache/words.d
.DYNAMIC: cache/words.d

cache/words.d: src/*.txt
	printf 'cache/words.json: src/hello.txt\n'
		

On-demand targets with ~

~cache/report/summary.pdf: cache/report/summary.pdf.d
	generate-report --deps "$<" --out "$@"
		

Prefixing the target with ~ marks it on-demand: an aggregate such as hypermake public that reaches it through a prerequisite edge will not build it, while hypermake cache/report/summary.pdf builds it as the requested root. This is how pages link to delivery artifacts — ZIPs, PDFs, exports — without every linked artifact joining the default build.

Dynamic dependencies:.d producers

Discovery never hides in a command body or an include. A target ending in .d is a dependency manifest: a .VIRTUAL + .DYNAMIC target, owned by its own *.d.make file, whose captured value is Make-syntax edges. This site discovers every page's reads that way:

.VIRTUAL: rendered/public/{path}.html.d
.DYNAMIC: rendered/public/{path}.html.d

rendered/public/{path}.html.d: src://{path}.html src/_components/*.html config.json
	hypermake d-manifest --target rendered/public/{path}.html --lzr-page --in src/{path}.html --template {path}.html --components-config config.json --components src/_components
		

The consumer lists the .d target as a normal prerequisite (see the first panel on this page). Expansion is consumer-scoped: the manifest's emitted rule must name the consuming target by its plain project-relative path — a manifest that names anything else fails the build with ".d manifest has no rule for target …". Emitted manifests may use backslash line continuations, unlike authored .make files. The producer's own rule still declares the matcher surface the edges can come from (src://{path}.html, the components glob, config.json), so the graph knows where future edges originate before they exist.

hypermake value rendered/public/docs/make-recipes.html.d
hypermake explain rendered/public/docs/make-recipes.html
		

Legacy escape hatches exist and lint: a body line @always maps to .ALWAYS, and @dynamic-prereq CMD runs an inline discovery command. Doctrine keeps graph discovery in .d.make producers, where the edges are inspectable state, not side effects. There is also a declarative JSON recipe form (a native-spec recipe source in hypermake.json) with fields beyond .make, such as digest targets and external-tool actions.

One artifact, one writer

Two recipes that can write the same output make the result depend on scheduling order, so overlap is an error, not a convention. Equal-precedence duplicates fail at load time. A recipe targeting DIR/.synced declares itself the sole materializer of DIR/** (the sync idiom: remove and repopulate the tree); any other recipe rooted under that tree raises diagnostics.overlapping_writer until it is either removed or sanctioned with .MULTI-WRITER. Locality is checked too: hypermake doctor flags files carrying more than one rule (recipe.multiple_targets_per_make, reason recipe.locality) — one target family should occupy one file.

Protocol addresses in rules

Targets and prerequisites may be spelled as protocol addresses; they resolve through the project's protocols mapping, and automatic variables hand commands the resolved filesystem paths. These are equivalent under this project's mapping of public to rendered/public:

# protocol form
public://assets/{asset}.css: src://assets/{asset}.css | rendered/public/assets/
# plain-path form (what this site's recipe authors)
rendered/public/assets/{asset}.css: src/assets/{asset}.css | rendered/public/assets/
		

cache:// outputs work the same way: a recipe may target derived state under cache://, and both request spellings — the plain path or the protocol address — reach the same rule. One caveat from above: inside a materialized .d manifest, spell the consuming target as its plain path.

Vocabulary, quoted from the system

These definitions are quoted from the binary-owned glossary at build time (public://_hypermake/site/concepts-recipes.json, materialized from hypermake explain concept://<term>), so this page cannot drift from the system that implements it.

hypermake match rendered/public/docs/make-recipes.html --json
hypermake explain rendered/public/docs/make-recipes.html
hypermake value rendered/public/docs/make-recipes.html.d
hypermake doctor
hypermake explain concept://recipe-doctrine