I Like Makefiles

Original Article ↗ Hacker News Discussion ↗

Make as Generic Task Runner

  • Many use Make not primarily for C/C++ builds but as a uniform “do stuff” interface: make build, make test, make dev, make deploy.
  • This gives a consistent entry point across diverse stacks (JS, Python, Rust, infra) and across repos.
  • Some treat writing a Makefile as part of initial project setup and as living documentation of workflows.

Strengths Cited

  • Ubiquity on Unix-like systems; often “already there” or one package away.
  • Simple mental model: rules state how to turn “files like this into files like that” with commands.
  • Built-in dependency tracking and incremental builds work very well for many projects.
  • Tab completion of targets, simple CLI (make target1 target2), and easy chaining of tasks.
  • Extremely stable over decades; backward compatibility praised.

Criticisms and Limitations

  • Syntax quirks: tab vs spaces, strange error messages, cryptic variables, per-line shells unless configured.
  • Conceptual mismatch when used purely as a task runner: targets are files by design, not commands.
  • Poor support for dynamic or multiple outputs (e.g., Fortran/C++ modules) without hacks; dynamic dependencies can be painful.
  • No built-in scripting language; non-POSIX features like .ONESHELL and .RECIPEPREFIX are GNU-only.
  • Portability issues across different make implementations (POSIX, BSD, GNU, nmake).

.PHONY and Correct Usage Debates

  • Strong consensus that non-file targets should be marked .PHONY to avoid confusing “up to date” behavior when files/dirs share names with targets.
  • Some argue misuse (treating Make purely as a script runner, ignoring dependencies) “gives Make a bad name.”
  • Others emphasize pragmatism: for small projects, imperfect Makefiles are acceptable and problems are rare and fixable.

Alternatives Proposed

  • For command-running: just, Taskfile, makesure, simple shell/PowerShell/Python scripts, NPM scripts, Gulp.
  • For full build systems: CMake, Ninja, Meson, Buck2, Bazel, Gradle, Mill, SCons, Xmake, Nix, Earthly, GN, language-native tools (cargo, npm, maven, etc.).
  • Disagreement on whether these are “better” or just differently painful.

Learning, Resources, and AI

  • Several recommend the GNU Make manual, online tutorials, and example-heavy guides.
  • LLMs are seen as making Make/Bash more approachable by generating or translating Makefiles.
  • Some see Make as “good enough and immortal”; others hope for a “lessons-learned Make” to eventually replace it.