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

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.