Ramblings of an aging IT geek
← Ramblings of an aging IT geek
tooling

the makefile as a project's front door

Using a plain Makefile as the memorable entry point for any project, C or not, so common tasks live in one obvious place.

A keyboard and terminal

Make has a reputation as a C build tool, and that reputation does it a disservice. For most of my projects, none of which are C, the Makefile isn't building anything. It's the front door. The one place anyone can look to find out how to run the tests, start the dev server, or ship the thing, without reading the README and without me explaining it for the third time.

.PHONY: test run build deploy

test:
	go test ./...

run:
	go run ./cmd/server

deploy: test
	./scripts/deploy.sh

The value is entirely that make test and make deploy are the same words in every project I own. I don't have to remember whether this one uses npm scripts or a shell file or some bespoke runner buried in a bin directory. Muscle memory carries across the whole lot. New person on the project? Read the Makefile, you have the verbs.

Two things bite. The first is the tab. Recipe lines must be indented with a real tab, not spaces, and Make's error when you get it wrong (missing separator) tells you nothing useful. The second is that Make assumes a target name is a file. If you ever make a file called test, your test target stops running because Make decides it's already up to date. .PHONY is the spell that says "this is a command, not a file", and you want it on every task target.

It's not glamorous, and there are fancier task runners. But Make is already on the box, it needs no config beyond the one file, and the file is short enough to read in ten seconds. That's the whole pitch.