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
.PHONYtargets into a single line is controversial:- Critics say
.PHONYshould 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.
- Critics say
- 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.