⚙️ Compiler & Toolchain Mastery

Makefiles: builds that rebuild themselves

⏱ 15 min · free interactive lesson · quizzes, visualizations & a real compiler

Your projects are no longer one file. Recompiling everything after each edit is slow, and a shell script that always rebuilds all of it is no better — it doesn't know what changed. make (born 1976, still everywhere) solves exactly this: you declare which files depend on which, and it rebuilds only what's out of date, by comparing file timestamps.

Our project: three files

A little calculator split the way you learned in the header-organization lesson:

/* calc.h — shared interface */
int add(int a, int b);
int mul(int a, int b);

/* calc.c — implementation: includes calc.h */
/* main.c — CLI:            includes calc.h */

▶ This spot has an interactive flow widget — open the interactive lesson to play with it.

Anatomy of a rule

A Makefile is a list of rules, each saying: this target is built from these prerequisites using this recipe:

app: main.o calc.o
	gcc main.o calc.o -o app

main.o: main.c calc.h
	gcc -Wall -c main.c -o main.o

calc.o: calc.c calc.h
	gcc -Wall -c calc.c -o calc.o

# target: prerequisites
# <TAB>   recipe  — that indent is a REAL tab character!

The logic when you run make app: if app is missing, or older than any prerequisite, run the recipe — after recursively ensuring each prerequisite is itself up to date. That's the entire algorithm. Timestamps in, minimal rebuilds out.

First run, then the magic

$ make
gcc -Wall -c main.c -o main.o
gcc -Wall -c calc.c -o calc.o
gcc main.o calc.o -o app
$ make
make: 'app' is up to date.
$ touch calc.c              # pretend we edited it
$ make
gcc -Wall -c calc.c -o calc.o
gcc main.o calc.o -o app
# main.o untouched — make compared timestamps and skipped it.

Touch one source file and only two commands run — recompile that object, relink. Touch nothing and make proudly does nothing. On a project with 2,000 files this is the difference between 2 seconds and 20 minutes.

Variables and automatic variables

Version 1 repeats itself badly. Make has variables (CC, CFLAGS are conventions the whole world uses) and automatic variables that mean "the current rule's parts":

CC     := gcc
CFLAGS := -std=c17 -Wall -Wextra -g
OBJS   := main.o calc.o

app: $(OBJS)
	$(CC) $^ -o $@

%.o: %.c
	$(CC) $(CFLAGS) -c $< -o $@

.PHONY: all clean
all: app
clean:
	rm -f app $(OBJS)

The %.o: %.c pattern rule says: any .o is built from the matching .c like so — one rule replaces a rule per file. And .PHONY marks all/clean as command names, not files: without it, a file literally named clean in your directory would make make clean report "up to date" and do nothing.

The header problem — and its modern fix

Subtle bug in v2: edit calc.h and… nothing rebuilds! Make only knows the dependencies you declare, and we declared none on headers. Hand-listing them rots instantly. The modern fix: ask GCC itself to emit dependency files as a side effect of compiling (-MMD -MP produce a .d makefile-fragment per object), then include them:

CC     := gcc
CFLAGS := -std=c17 -Wall -Wextra -g -MMD -MP
OBJS   := main.o calc.o

app: $(OBJS)
	$(CC) $^ -o $@

%.o: %.c
	$(CC) $(CFLAGS) -c $< -o $@

-include $(OBJS:.o=.d)

.PHONY: clean
clean:
	rm -f app $(OBJS) $(OBJS:.o=.d)

$ make
gcc -std=c17 -Wall -Wextra -g -MMD -MP -c main.c -o main.o
gcc -std=c17 -Wall -Wextra -g -MMD -MP -c calc.c -o calc.o
gcc main.o calc.o -o app
$ cat main.d
main.o: main.c calc.h
calc.h:
$ touch calc.h && make      # NOW header edits are seen:
gcc -std=c17 -Wall -Wextra -g -MMD -MP -c main.c -o main.o
gcc -std=c17 -Wall -Wextra -g -MMD -MP -c calc.c -o calc.o
gcc main.o calc.o -o app

Beyond make

Big projects today usually generate their build instead of hand-writing it: CMake and Meson describe the project at a higher level and emit Makefiles (or the faster Ninja) for any platform, handling dependency discovery and cross-compilation. They're worth learning eventually — but they generate exactly the concepts you just learned, so none of this knowledge is wasted; it's the assembly language of build systems.

Your build now takes care of itself — time to master the tools for when the program misbehaves: gdb, valgrind, and the sanitizers.