Makefiles — targets, prerequisites, recipes, variables, automatic variables: Exercises

Prerequisite ideas you may want open in another tab: Compilation Pipeline, Incremental Compilation, Directed Acyclic Graphs (DAG), Shell Scripting Basics.

Definition The two words of logic we will use (read this first)

Two little symbols show up in Make's rebuild law. They come from predicate logic, a shorthand for "true/false statements about things." We define them once, in plain words, and never use another logic symbol beyond these:

== $\neg$ (NOT)== flips a true/false statement. If a statement $S$ is true, then $\neg S$ is false, and vice-versa. Read $\neg exists (T)$ as " $T$ does not exist."
== $\lor$ (OR)== joins two statements and is true when at least one side is true. Read $A \lor B$ as " $A$ is true, or $B$ is true, or both."
== $\exists i$ (THERE EXISTS)== means "there is at least one value of the counter $i$ for which the following statement holds." Read $\exists i : t (P_{i}) > t (T)$ as "there is at least one prerequisite $P_{i}$ that is newer than $T$ ." That's the entire logic vocabulary this page needs.

Definition Timestamps, the file universe, and the rebuild law

Every name we discuss — a target, a prerequisite, main.c, app — is a file (or a label pretending to be one). Let the letters $T$ , $P_{i}$ , and $X$ all range over that same universe of files; they are just different roles for the same kind of thing (a target file, a prerequisite file, or any file $X$ in general).

We write == $t (X)$ == for the modification time of a file $X$ — the "last changed" clock stamp the operating system keeps on every file. A larger number means newer.
The predicate == $exists (T)$ == means "a file named $T$ is physically present on disk." It is true if the file is there and false if it was never built or was deleted. Since $T$ is just a file, $exists$ and $t$ speak about the same objects — $exists (T)$ asks whether $T$ is on disk, and if it is, $t (T)$ reads its clock. The full rebuild law, now fully readable, is: $rebuild (T) ⟺ \neg exists (T) \lor \exists i : t (P_{i}) > t (T)$ In words: rebuild $T$ if $T$ does not exist on disk, OR if there is at least one prerequisite $P_{i}$ newer than $T$ .

Level 1 — Recognition

Recall Solution L1.1

Target ::: report.pdf — the file we want to produce.
Prerequisites ::: report.tex figures.png — the inputs it depends on.
Recipe ::: pdflatex report.tex — the shell command that builds it. The recipe line (pdflatex ...) must begin with a literal TAB. The target: prerequisites line begins in column 0 with no TAB.

Recall Solution L1.2

$^ — all prerequisites.
$@ — the target.
$< — first prerequisite.
$? — the stale (newer) prerequisites.
$* — the pattern stem. Why does $^ remove duplicates, and in what order? A file can legitimately be listed as a prerequisite twice — for example a shared header named in two different rule fragments that Make merges. When you feed prerequisites to a linker or compiler via $^, passing the same file twice can cause errors (e.g. "duplicate symbol") or simply waste work. So Make keeps only the first occurrence of each file and drops later repeats, which means it preserves the original left-to-right order of first appearances. (If you genuinely need the duplicates, $+ is the variant that keeps them — but $^ is the safe default.)

Level 2 — Application

Worked example L2.1 — Expand the automatic variables

Given:

%.o: %.c common.h
	gcc -c $< -o $@

and the target parser.o matched from parser.c (so prerequisites are parser.c common.h), write the exact expansion of $<, $@, $^, and $*.

Recall Solution L2.1

$< = parser.c (first prerequisite).
$@ = parser.o (the target).
$^ = parser.c common.h (all prerequisites, in order, duplicates removed).
$* = parser (the stem the % matched). The actual command that runs is: gcc -c parser.c -o parser.o. Note common.h never appears in the command even though it is a prerequisite — it forces a rebuild if the header changes, but the compile line only feeds the .c.

Recall Solution L2.2

Why does this operate on each word? Make treats a variable's value as a list of words separated by whitespace — that is Make's fundamental data model (spaces, not commas, are the delimiter). Make first tokenizes SRCS into three words main.c, parser.c, io.c, then applies the suffix rewrite to each token independently, then rejoins them with single spaces. That is why the rule "replace the trailing .c with .o" acts per file and not on the string as a whole:

OBJS = main.o parser.o io.o

Similarly $(SRCS:.c=.d) = main.d parser.d io.d. The pattern is $(VAR:suffix=replacement) — it only rewrites the trailing suffix, per word.

Worked example L2.3 — Rewrite with a pattern rule

These three near-identical rules cry out for DRY. Rewrite them as one pattern rule.

a.o: a.c
	gcc -Wall -c a.c -o a.o
b.o: b.c
	gcc -Wall -c b.c -o b.o
c.o: c.c
	gcc -Wall -c c.c -o c.o

Recall Solution L2.3

CFLAGS := -Wall
%.o: %.c
	gcc $(CFLAGS) -c $< -o $@

The % matches the stem (a, b, c); $< becomes each .c; $@ becomes each .o. One rule now covers all three files and any future ones.

Level 3 — Analysis

Here we reason about timestamps — the heart of Make, using the rebuild law defined at the top of the page. Study the figure below: it is a small dependency DAG with timestamps attached.

Figure — Makefiles — targets, prerequisites, recipes, variables, automatic variables

Figure s01 — DAG for L3.1. Three layers, arrows point from a prerequisite to the thing built from it ("built from"). Bottom layer = source files: main.c (t=10, teal), utils.h (t=12, plum), utils.c (t=5, teal). Middle layer = objects: main.o (t=8, orange) fed by main.c and utils.h; utils.o (t=9, orange) fed by utils.c and utils.h. Top = app (t=11, ink) fed by both objects. The shared utils.h (t=12) is the newest source, so it is the trouble-maker: it sits below both objects, meaning both objects have a prerequisite newer than themselves.

Intuition What "post-order traversal" means, walked on Figure s01

Post-order = visit all of a node's children before the node itself. Trace it on the arrows in Figure s01, starting from the top node app:

To settle app, first settle its children main.o and utils.o (you cannot judge app until its inputs are final).
To settle main.o, first settle its children main.c and utils.h (bottom layer — nothing below them, so they are settled immediately).
Same for utils.o.
Only now, walking back up the arrows, do you decide main.o, then utils.o, then finally app. Why this order and not top-down? If you judged app first, its object timestamps might still be about to change — you'd compare against stale numbers. Post-order guarantees every input is final before you look at it. Visually: you always finish everything below an arrow before crossing it upward.

Worked example L3.1 — Which targets rebuild?

Using the timestamps in the figure (larger number = newer):

main.c: t=10   utils.c: t=5    utils.h: t=12
main.o: t=8    utils.o: t=9    app: t=11

Rules:

app: main.o utils.o
main.o: main.c utils.h
utils.o: utils.c utils.h

Decide, in post-order, which of main.o, utils.o, app get rebuilt, and give the final state.

Recall Solution L3.1

Work bottom-up (post-order: prerequisites before target, exactly the walk in Figure s01). Recall from the "how we model now" definition that each rebuilt file is stamped one greater than the current maximum timestamp, so it lands strictly above everything built so far. The starting maximum is 12 (utils.h).

main.o (t=8): prereqs main.c (t=10) and utils.h (t=12). Is any newer than 8? Yes, both. → rebuild. Current max is 12, so the new stamp is $12 + 1 = 13$ : t(main.o) becomes 13.
utils.o (t=9): prereqs utils.c (t=5), utils.h (t=12). Is any newer than 9? utils.h (12) > 9 → rebuild. Current max is now 13, so the new stamp is $13 + 1 = 14$ : t(utils.o) becomes 14.
app (t=11): prereqs main.o (now 13) and utils.o (now 14) — both just got newer than 11. → rebuild. New stamp $14 + 1 = 15$ . Final: all three rebuild. The key insight: even though app was newer than the old object times, rebuilding the objects made them newer, which cascades up. (The exact numbers 13, 14, 15 are just bookkeeping; the only fact that matters is "each rebuilt file is newer than everything before it.")

Worked example L3.2 — The "nothing to do" case

Same rules, but now timestamps are:

main.c: t=1   utils.c: t=1   utils.h: t=1
main.o: t=5   utils.o: t=5   app: t=9

Which targets rebuild? What message does Make print for make app?

Recall Solution L3.2

main.o (5): prereqs at t=1, all older → up to date, skip.
utils.o (5): prereqs at t=1 → skip.
app (9): prereqs main.o(5), utils.o(5), both older than 9 → skip. Nothing is stale. Make prints:

make: 'app' is up to date.

Worked example L3.3 —

$? in a copy step A rule installs headers only when they change:

install: a.h b.h c.h
	cp $? /usr/include/

Suppose the target install has t=20, and a.h=25, b.h=10, c.h=30. install is a normal file here. What does $? expand to, and what command runs?

Recall Solution L3.3

$? = prerequisites newer than the target (t=20). Compare each: a.h(25>20 ✓), b.h(10>20 ✗), c.h(30>20 ✓).

$? = a.h c.h

Command run: cp a.h c.h /usr/include/. Only the two changed headers are copied — that's the whole point of $?.

Level 4 — Synthesis

Recall Solution L4.1

CC      := gcc
CFLAGS  := -Wall -Wextra -O2
TARGET  := calc
SRCS    := main.c stack.c eval.c
OBJS    := $(SRCS:.c=.o)
 
.PHONY: all clean
 
all: $(TARGET)
 
$(TARGET): $(OBJS)
	$(CC) $^ -o $@
 
%.o: %.c defs.h
	$(CC) $(CFLAGS) -c $< -o $@
 
clean:
	rm -f $(OBJS) $(TARGET)

Key choices: := snapshots OBJS = main.o stack.o eval.o. The pattern rule lists defs.h as a prerequisite so touching the header rebuilds every object, but uses $< so only the .c is compiled. Linking uses $^ (all objects) and $@ (calc).

Recall Solution L4.2

Add run to the single existing .PHONY line (do not write a second .PHONY), then add the rule:

.PHONY: all clean run
 
run: $(TARGET)
	./$(TARGET) 2+2

Best practice: group all phony targets on one .PHONY declaration rather than sprinkling several. run depends on $(TARGET), so Make builds calc first (post-order), then runs ./calc 2+2. Because run is phony, it executes every time even if a file named run exists.

Level 5 — Mastery

Worked example L5.1 — Recursive vs simple, traced

Predict the printed values. Assume $(info X) prints X at the moment the line is read (parse time), not later.

A = 1
B = $(A)
C := $(A)
A = 2
$(info B is $(B))
$(info C is $(C))
A = 3
$(info B again $(B))
$(info C again $(C))

Recall Solution L5.1

B = $(A) is recursive: B stores the expression $(A), re-read each use.
C := $(A) is simple: at that line A=1, so C snapshots 1. When the $(info ...) lines run, A has been reassigned:
B is 2 — because at that point A=2 and B re-reads it.
C is 1 — snapshot never changes.
B again 3 — A is now 3, B re-reads again.
C again 1 — still the frozen snapshot.

Worked example L5.2 — Predict the exact build actions

Given the DAG in Figure s02 below and starting timestamps

foo.c=100  bar.c=100  foo.h=200
foo.o=150  bar.o=150  prog=250

with rules

prog: foo.o bar.o
	ld foo.o bar.o -o prog
foo.o: foo.c foo.h
	cc -c foo.c -o foo.o
bar.o: bar.c
	cc -c bar.c -o bar.o

Before reading the solution, use Figure s02: find the one bottom-layer node whose timestamp is higher than the object above it — that plum "STALE" tag tells you which object must rebuild. Then list exactly which recipes run, in order, for make prog.

Figure s02 — Build trace for L5.2. Same three-layer shape. Bottom: foo.c (t=100), foo.h (t=200, plum), bar.c (t=100). Middle: foo.o (t=150) built from foo.c and foo.h; bar.o (t=150) built from bar.c. Top: prog (t=250). The plum tag near foo.o reads "200>150 STALE" — its prerequisite foo.h is newer, so foo.o must rebuild. The teal tag near bar.o reads "100<150 fresh" — bar.c is older, so bar.o is skipped. Following the post-order walk (children before parent), you settle the bottom sources, then foo.o (rebuild) and bar.o (skip), then prog.

Recall Solution L5.2

Read the tags in Figure s02 first: the plum "200>150 STALE" tag on foo.o and the teal "100<150 fresh" tag on bar.o already hand you the two verdicts. Now confirm them with the post-order walk from prog (children before parent). The starting maximum timestamp is 250 (prog).

foo.o (150): prereqs foo.c(100), foo.h(200). foo.h 200>150 → rebuild (matches the plum tag). Runs cc -c foo.c -o foo.o. New stamp = current max + 1 = $250 + 1 = 251$ .
bar.o (150): prereq bar.c(100). 100 < 150 → up to date, skip (matches the teal tag). No command.
prog (250): prereqs foo.o(now 251) and bar.o(150). foo.o 251>250 → rebuild. Runs ld foo.o bar.o -o prog. Commands that actually run, in order:

cc -c foo.c -o foo.o
ld foo.o bar.o -o prog

bar.o is not recompiled — this is exactly the incremental win Make gives you, and Figure s02's teal "fresh" tag is the visual reason.

Recall Solution L5.3

Each edited .c is newer than its .o → 2 compiles run.
The other 4 objects are up to date → 0 of those compiles run.
The 2 rebuilt objects become newer than the binary → the link rule runs → 1 link. $recipes run = 2 + 1 = 3$ Out of a possible 7 recipes, only 3 fire — Make skipped 4 unnecessary compiles.

Worked example L5.4 — Order-only prerequisites (the

| edge case) You want every object placed in a build/ directory that must exist before compiling, but you do not want the directory's ever-changing timestamp to trigger rebuilds. Given:

build/%.o: %.c | build
	gcc -c $< -o $@
 
build:
	mkdir -p build

Question: what is the role of the | separator, and why would writing build/%.o: %.c build (no |) be a bug?

Recall Solution L5.4

The | splits the prerequisite list into two kinds:

Normal prerequisites (left of |, here %.c): a change in these — newer timestamp — triggers a rebuild.
Order-only prerequisites (right of |, here build): Make guarantees these are made first, but their timestamp is never compared to the target. They enforce ordering only. Why plain build (no |) is a bug: a directory's modification time bumps every time a file is added to it. If build were a normal prerequisite, then compiling the first object updates build's timestamp, making it newer than the other objects — so every subsequent make would needlessly recompile them all. The | says "just make sure the folder exists first; don't watch its clock." Order-only prerequisites are also excluded from $^ and $< — only normal prerequisites appear there, so $< here is still just %.c.

Worked example L5.5 — Static pattern rules and multiple targets (advanced edge cases)

Two more edge cases that trip up experts: (a) Static pattern rule. Explain what this builds and why it is safer than a plain %.o: %.c:

OBJS := main.o util.o
$(OBJS): %.o: %.c
	gcc -c $< -o $@

(b) Multiple targets in one rule. For the rule below, what does $@ expand to when Make needs a.out, and does the recipe run once or twice if both a.out and b.out are stale?

a.out b.out: shared.c
	gcc shared.c -o $@

Recall Solution L5.5

(a) A static pattern rule has the form targets: target-pattern: prereq-pattern. Here the target list is restricted to exactly main.o and util.o — the %.o: %.c part only applies to those two names, matching each against its .c. Why safer than plain %.o: %.c? A bare pattern rule would fire for any X.o Make ever wants, possibly catching files you never intended (e.g. a .o that should be built a different way). The static form scopes the pattern to a known, explicit list, so it can never fire on a surprise target. $< is main.c / util.c; $@ is main.o / util.o respectively. (b) For an ordinary rule with multiple targets (single colon), Make treats it as shorthand for one separate rule per target, each sharing the same prerequisites and recipe. So:

When Make needs a.out, $@ = a.out; the recipe runs as gcc shared.c -o a.out.
When Make needs b.out, $@ = b.out; the recipe runs again as gcc shared.c -o b.out. If both are stale, the recipe runs twice, once per target — because each target got its own copy of the rule. (This is a classic gotcha: people expect one invocation. If you truly want a single command to produce both outputs at once, you need a grouped target with &:, i.e. a.out b.out &: shared.c.)

Recap

Recall Self-check before you leave

Post-order traversal, why? ::: Make must ensure every prerequisite is up to date before comparing timestamps against the target, so it builds children first. $? vs $^? ::: $? = only prerequisites newer than the target (the stale ones); $^ = all prerequisites. Why does $^ de-duplicate, and in what order? ::: To avoid passing the same file twice to a linker/compiler; it keeps the first occurrence, preserving left-to-right order. = vs := in one line? ::: = re-expands lazily each use; := snapshots the value once at definition. What does exists(T) mean in the rebuild law? ::: A file named T is physically present on disk; if false, Make must build. What do the logic symbols mean? ::: $\neg$ = NOT (flip true/false), $\lor$ = OR (at least one side true), $\exists i$ = there is at least one $i$ . What does a | in a prerequisite list do? ::: Marks order-only prerequisites — made first but their timestamp never triggers a rebuild, and they are excluded from $^{a} n d$ <. Multiple targets in one ordinary rule — how many times does the recipe run if both are stale? ::: Twice — Make expands it into one rule per target. Editing one shared header with N dependents triggers how many object rebuilds? ::: All N — the header is a prerequisite of every one.

Connections

Parent: Makefiles — targets, prerequisites, recipes, variables, automatic variables (index 5.3.6)
Directed Acyclic Graphs (DAG) — the shape Make traverses.
Incremental Compilation — the payoff of skipping up-to-date objects.
Compilation Pipeline · Linkers and Object Files — what the compile and link recipes actually do.
CMake and Build Generators — a tool that writes Makefiles for you.
Shell Scripting Basics — recipes are shell commands.