Mbake – A Makefile formatter and linter, that only took 50 years

Original Article ↗ Hacker News Discussion ↗

A new tool called Mbake aims to format and lint Makefiles, prompting reactions that range from enthusiasm—especially for editor integration and CI use—to skepticism about how aggressive formatting might erase human semantic cues in complex build scripts. Commenters branch into a broader debate over the role of `make` itself: whether it’s a misused file-based build system turned task runner, or a still-valuable, ubiquitous way to declaratively model dependency graphs across languages and environments. The choice of Python for implementing Mbake also reignites long-running tensions around Python’s packaging and distribution pain versus its huge ecosystem and accessibility compared to “cleaner” but less widely adopted languages.

Tool reception & integration

  • Many welcome a Makefile formatter/linter and intend to try it; some note similar tools have existed (makel, unmake, checkmake, make-audit, editor linters), so “50 years” is seen as exaggeration.
  • Suggestions to:
    • Package it as a pre-commit hook.
    • Use the existing VS Code extension; some missed this in the README on mobile.
    • Provide inline “ignore” syntax for individual rules as an escape hatch.
  • An AUR package is already available.
  • One commenter asks how it differs from earlier Makefile linters/formatters; this remains unclear.

Formatting philosophy & .PHONY handling

  • Consolidating .PHONY targets into a single line is controversial:
    • Critics say .PHONY should sit next to each rule, both for readability and to avoid desynchronization (e.g., listing a phony target that doesn’t exist).
    • Others point out this grouping is configurable and like the reduced clutter.
  • Concern that some Makefiles use indentation/variable placement as semantic cues. Mechanical rewriting risks losing this “human context.”
  • Counterpoint: this tension exists for any language formatter; many still prefer automatic formatting with some configurability.

Make as tool: love, hate, and alternatives

  • Strong defenses of make:
    • Ubiquitous (POSIX, common on minimal systems), language/tooling agnostic “enough,” declarative, good for reproducible “make run / make test” workflows and CI.
    • Lets you define a DAG of tasks with dependencies and incremental rebuilding.
  • Criticisms:
    • Environment-variable–centric configuration is seen as bad DX and a source of subtle bugs (“spooky action at a distance,” sudo/containers quirks).
    • Make is “make file”: originally about file timestamps, now widely (mis)used as a general task runner.
  • Alternatives mentioned:
    • Tup as a more rigorous build system with better incremental performance, but with less mindshare and more constraints.
    • Rake/other task runners or plain shell/CI scripts for task orchestration.

Language choice (Python) and distribution

  • Some debate around Python:
    • Acknowledged: tricky installs, dependency mess, poor performance, hard packaging vs compiled languages.
    • But its ecosystems and user base dwarf most “better” languages; newcomers adopt it easily; many tools will continue to be written in it.
  • Pushback that pip install … as primary install path excludes many users; binary or OS-package distribution is preferred.
  • Several participants describe moving away from Python for tools (except stdlib-only scripts) due to dependency and multi-interpreter pain.