[HN Gopher] Mbake - A Makefile formatter and linter, that only t...
___________________________________________________________________
Mbake - A Makefile formatter and linter, that only took 50 years
Author : rainmans
Score : 206 points
Date : 2025-06-20 01:06 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jtwaleson wrote:
| Nice, would be good to package this as a https://pre-commit.com/
| hook.
| foma-roje wrote:
| It really doesn't have to be complicated for it to be useful.
| Plenty thanks for sharing this.
| x3n0ph3n3 wrote:
| I don't understand why people like make so much. Interacting with
| CLI tools using only env vars as arguments is cartoonishly bad
| dev experience.
| zabzonk wrote:
| You can pass arguments via the command line (it is, after all,
| a CLI tool):
| https://stackoverflow.com/questions/2826029/passing-addition...
| lmz wrote:
| I mean there's really not much difference between "VAR=val
| make x" and "make x VAR=val" now is there?
| marginalia_nu wrote:
| Syntactically? No. Semantically? Yes.
| lmz wrote:
| I'm guessing the syntax was the part the poster was
| complaining about when they complained about the "dev
| experience".
| marginalia_nu wrote:
| Dunno, there are other aspects of environment variables
| that deteriorate the dev experience. They're very
| conducive to spooky action at a distance, since they're
| silently being passed along from parent-process to child-
| process (except when they aren't).
|
| They can cause a lot of annoying bugs, and sometimes it's
| hard to track down where they are coming from (especially
| when dealing with stuff running in containers).
| 77pt77 wrote:
| > except when they aren't
|
| Like sudo for example.
|
| So many problems related to that.
| hiAndrewQuinn wrote:
| I often prefer to work in _in extremis_ environments where
| there is no internet access, and hence, no easy way to get
| ahold of make; it 's given me a bad habit of just waiting a
| build.bash script to do what make does most of the time. I
| haven't really found myself missing it that much.
| M0r13n wrote:
| I am confused, because this means that you won't be able to
| install anything. No compiler, no 3rd party libraries and no
| text editor that isn't preinstalled
| 0points wrote:
| If you can install bash on your airgapped dev box, why
| wouldn't you install make on it? Make is part of the core dev
| environment on just about every disto under the sun.
| 77pt77 wrote:
| most minimal setups nowadays have bash, make and even perl.
| georgyo wrote:
| I'm not so sure most people would agree with you. Though I
| think plenty would.
|
| I dare say that developers like environment variables more than
| before. Consider that Docker images, and hence Helm charts, are
| entirely controlled via environment variables. These very
| popular dev tools suffer from the same problem of having near-
| zero easy discoverability of what those environment variables
| might be. Yet they are very popular.
|
| But I don't think Make usually uses all that many environment
| variables. You're usually specifying build targets as the
| command line arguments. Automake and autogen usually generate
| these makefiles with everything hard-coded.
|
| Also, it makes it very easy to get started with, and it is
| universally available. Makes it very easy to like.
| globular-toast wrote:
| It's 80% of what you want and it's installed everywhere.
|
| You could go for something closer to exactly what you want, but
| now you've got an extra set up step for devs and something else
| for people to learn if they want to change it.
|
| I would say if you're looking for cli args then you shouldn't
| be using any wrapper like make at all. Just call the underlying
| tool directly. Make is for doing big high level things in the
| standard way, nowadays quite often in CI pipelines.
| zelphirkalt wrote:
| Yep, that's how I used it on the job before. "make test"
| would run tests locally and in CI pipeline, keeping the CI
| file refreshingly short at that point.
| zelphirkalt wrote:
| Make allows you to specify dependencies for you targets, which
| are also targets. As such you do not need to rely on brittle
| string concatenation approaches. It is a tool build for this.
|
| I personally like going to a project folder and run "make run",
| no matter what language or setup I have, to run the project. It
| enables me to unify access to projects.
|
| I also take great care to make these runs reproducible, using
| lock files and other things of the ecosystems I am using,
| whenever possible. I work on another machine? git clone, make
| run. Or perhaps git clone, make init, make run.
| danlitt wrote:
| Make is in POSIX, so it's generally available. Same reason
| people write shell scripts (even if the scripts are not
| generally POSIX-only).
| bshacklett wrote:
| Unless your company forces you to use Windows, which is still
| much more common than many would like to admit. And yes, WSL
| exists, but in my experience, if a company is unwilling to
| allow macOS, there's a good chance they either don't allow
| enabling HyperV, or the security software they use is such
| garbage that it results in a HyperV enabled system being
| effectively unusable.
| pjmlp wrote:
| Windows 11 requires Hyper-V turned on, virtualization based
| security is one of the reasons of the forced hardware
| upgrades.
| PhilipRoman wrote:
| You don't have to write Make invocations by hand... It's just a
| tool that can be called from any editor or IDE (or by automatic
| file watchers). Environment variables aren't really relevant to
| Make either, unless you really want to misuse it as a command
| runner.
| cerved wrote:
| I like it because it's language and tooling agnostic,
| declarative, fast and ubiquitous.
|
| Where it's less great is complicated recipes and debugging
| xigoi wrote:
| Make is not language agnostic; it has implicit rules for
| compiling C.
| pheggs wrote:
| it also has implicit rules for other languages, why would
| that make it non-agnostic?
| aboardRat4 wrote:
| Because make is a prolog in disguise.
| gjvc wrote:
| you don't do it naked, you write and use wrapper scripts to
| make it ergonomic
| motorest wrote:
| > Interacting with CLI tools using only env vars as arguments
| is cartoonishly bad dev experience.
|
| Make excels at what it's design to do: specify a configurable
| DAG of tasks that generate artifacts, execute them, and
| automatically determine which subgraph requires updates and
| which can be skipped by reusing their artifacts.
|
| I wonder: which tool do you believe does this better than Make?
| system33- wrote:
| Tup. https://gittup.org/tup/
| https://gittup.org/tup/make_vs_tup.html
|
| But the Internet's make mind-share means you still have to
| know make.
|
| Edit: and make lets you use make to essentially run
| scripts/utils. People love to abuse make for that. Can't do
| that with tup.
| aDyslecticCrow wrote:
| Abuse? Runnig linters, code analysers, configuration tools,
| template engines, spellcheckers, pulling dependencies,
| building dependencies with different build systems.
|
| Sufficiently complex project need to invole alot of wierd
| extra scripts, and if a build system cannot fulfil it...
| the n it needs to be wrapped in a complex bash script
| anyway.
| motorest wrote:
| > Tup.
|
| I don't think Tup managed to present any case. Glancing at
| the page, the only conceivable synthetic scenarios where
| they can present Tup in a positive light is built times of
| > 10k files, and only in a synthetic scenario involving
| recompiling partially built projects. And what's the upside
| of those synthetic scenarios? Shaving w couple of seconds
| in rebuilds? That's hardly a compelling scenario.
| kiitos wrote:
| > Tup
|
| `tup` relies on a stateful database, which makes it
| incomparable to `make`.
| Crier1002 wrote:
| ive always wanted this. im going to give it a go!
|
| does this happen to support IDE like vscode?
| antonhag wrote:
| From the readme: VSCode Extension 1.
| Open VSCode 2. Go to Extensions (Ctrl+Shift+X)
| 3. Search for "mbake Makefile Formatter" 4. Click
| Install
| Crier1002 wrote:
| thanks! apologies i was on mobile and missed this. im excited
| to try it out
| s4i wrote:
| Does this support inline ignoring specific rules with some
| syntax? Couldn't find this from the README. Would be good to have
| as an escape hatch.
| pjmlp wrote:
| I am quite certain to have used such kind of tooling during
| 1990's, with ads on The C/C++ Users Journal and Dr. Dobbs
| developer magazines.
| JdeBP wrote:
| It wouldn't have been Matthias Andree's makel, then.
|
| * https://git.maandree.se/makel
|
| Or unmake.
|
| * https://crates.io/crates/unmake
|
| Or checkmake.
|
| * https://github.com/checkmake/checkmake
| (https://news.ycombinator.com/item?id=32460375)
|
| Or make-audit.
|
| * https://github.com/david-a-wheeler/make-audit
|
| Or the Sublime linter for makefiles.
|
| * https://github.com/giampaolo/SublimeLinter-contrib-makefile
|
| It hasn't taken quite the 50 years that we are told, has it?
| (-:
| 1oooqooq wrote:
| ewwww. consolidated phony lines. everyone knows these should be
| right before each rule declaration.
| leetrout wrote:
| Seems like from the README this can be disabled
| group_phony_declarations = false
|
| I think the visual clutter of .PHONY on each recipe declaration
| is better since there's always a lot of copy-paste coding.
| b0a04gl wrote:
| some Makefiles use indents or var placement as semantic cues. if
| a tool rewrites them mechanically, it might clean things while
| killing meaning. is structural correctness enough, or do we need
| formatters that preserve human context too?
| iib wrote:
| Ideally, we'd have linters that preserve the human context as
| well. But human context may be too ambiguous and high variance
| enough that it can be impractical.
|
| It's hard to say what's intent and what not, maybe linters with
| many custom rules would work best.
| jchw wrote:
| That doesn't sound any different than it is for any other
| programming language, but many people prefer automatic
| formatting anyways.
| kseistrup wrote:
| Here's an AUR package:
|
| https://aur.archlinux.org/packages/python-bake-git
| eabeezxjc wrote:
| simple use rake
| notnmeyer wrote:
| or any other task runner
| rurban wrote:
| Differences to checkmake, the older Makefile's linter and
| formatter?
| rednafi wrote:
| Thanks for the tool. This is pretty neat.
|
| It's almost comical to see "why Python" comments after all these
| years. I would've chosen Go to write this, but that's beside the
| point.
|
| Yes, Python installation is tricky, dependency management is a
| mess (even with uv, since it's not standard tooling; another one
| will pop up), and performance is atrocious. But even then, some
| Python libraries have bigger communities than the combined
| communities of all these "better, faster, more awesome"
| languages.
|
| Python is here to stay. Newcomers love it because you need to
| know so little to get started. People don't care about the little
| quirks when they begin, and eventually they just live with the
| warts. That's fine. LLMs write better Python than Go (my
| preferred language, or whatever yours is). And if you know
| anything about the AI research community, it's C++, C, Python or
| GTFO.
|
| Going forward, a lot more tools will be written in Python, mostly
| by people entering the field. On top of that, there's a huge
| number of active Python veterans churning out code faster than
| ever. The network effect keeps on giving.
|
| So whatever language you have in mind, it's going to be niche
| compared to Python or JS. I don't like it either. But if
| languages and tools were chosen on merit instead of tribalism, we
| wouldn't be in this JS clusterfuck on the web.
| kiitos wrote:
| > It's almost comical to see "why Python" comments ... Yes,
| Python installation is tricky, dependency management is a mess
| (even with uv, since it's not standard tooling; another one
| will pop up), and performance is atrocious. But ... Newcomers
| love it because you need to know so little to get started.
| People don't care about the little quirks when they begin, and
| eventually they just live with the warts.
|
| I'm not sure if this is news to you or if you already know it,
| but, just to be explicit -- you know that the overwhelming
| majority of end users aren't gonna have `pip` installed on
| their systems, right? And that any project with "Installation
| instructions" that begin with a `pip` command aren't really
| gonna work in the general case?
|
| Just wanna make sure that's well-understood... it's fine if you
| wanna build a tool in Python, but if you expect it to be
| practically usable, you need to do distribution of binaries,
| not `pip` targets...
| rednafi wrote:
| This point has been pummeled to death for decades. Before
| Python, people did the same with Ruby and "gem." Literally
| nothing is new here.
|
| One of the reasons I write my tools in Go is exactly this.
| But if the tool was written in Go, people would complain
| about why not Rust and such. The point wasn't to convey that
| Python doesn't have its fair share of flaws, but to
| underscore that the HN crowd doesn't represent any
| significant majority. The outside world keeps on using
| Python, and the number of Go or Rust users is most likely
| less than PyTorch or Scikit-learn users.
|
| Shipping Python is hard and the language is slow. Also,
| tooling is bad. The newfangled ones are just a few in the
| long stream of ad hoc tooling over the past 20 years. Yet
| people write Python and will continue to do so. JS has a
| similar story, but it's just a 10x worse language than
| Python.
| kiitos wrote:
| Let me be even more explicit: if your installation
| instructions are `pip install ...` -- or `npm install ...`
| for that matter -- then you are automatically excluding a
| super-majority of potential users.
| rednafi wrote:
| I don't even write python these days. I just wrote my own
| version of a terminal llm-caller[^1] in Go for this exact
| same reason.
|
| There's a famous one that does the same thing but is
| written in Python. So it has its issues.
|
| My point is, pip exists in most machines. pip install
| sucks but it's not the end of the world. HN crowd
| (including myself) has a tendency to beat around the bush
| about things that the majority don't care about IRL.
|
| [1]: https://github.com/rednafi/q
| callc wrote:
| I love python, have used it for years. I hate the dependency
| and multiple interpreter situation.
|
| A great PL should stand on its own without the need for
| external tooling.
|
| At this point I have given up on python except for if it's a
| little script that only uses standard libraries. Otherwise I'm
| choosing a compiled language.
|
| Some more thoughts: http://calvinlc.com/p/2025/06/10/thank-you-
| and-goodbye-pytho...
| TZubiri wrote:
| I use python without any dependencies on web servers. Pip is
| cool, but you don't need to get pulled into the node-like
| dependecy hell.
|
| For example instead of requests, you can use http.client,
| instead of flask, http.server, or socket.tcpserver, or just
| socket. If you want sqlite, don't jump to pip install sqlite
| or whatever, use sockets to talk to it.
| jonotime wrote:
| How do you use only sockets to talk to sqlite?
| rednafi wrote:
| Why do you need to do that when Python has built in
| sqlite3 support?
| blks wrote:
| it's harder to distribute software written in python via eg
| package manager compared to compilable languages.
| seanwilson wrote:
| Anyone else not bother maintaining a list of .PHONY targets?
| Always felt like a chore that adds noise for a rare edge case.
| leetrout wrote:
| > The implicit rule search (see Using Implicit Rules) is
| skipped for .PHONY targets. This is why declaring a target as
| .PHONY is good for performance, even if you are not worried
| about the actual file existing.
|
| https://www.gnu.org/software/make/manual/html_node/Phony-Tar...
| jbverschoor wrote:
| Makefile is "make file". It has been abused into being a task
| runner. The wrong tool for the job.
|
| The "make file" is all about file dependencies based on last
| modified date. Outdated target files can be rebuilt using source
| file. It's is dependency management and the essence of an
| incremental compiler, but all revolving around files, not tasks.
| tgv wrote:
| The nice thing about make is that is ubiquitous, and that it
| offers nice things out of the box.
| dima55 wrote:
| Right. It kinda sucks for that purpose too, which gives Make a
| bad name.
| kristopolous wrote:
| What gives make a bad name is the same thing that gave
| javascript or m4 a bad name - these things are their own
| exotic birds - doing them well require new concepts and new
| behaviors.
|
| You can indeed shoehorn them into what you know but really
| you need to fully embrace their weird world.
|
| See also forth, dc, awk, jq ...
|
| It'd be nice to have a dedicated crash course on these things
| for people who understand conventional programming and have
| been doing the normal stuff for a number of years.
|
| Also see supercollider, prolog, haskell, apl...
|
| I think the most mainstream exotic bird people learn is Lisp.
| Doing all these things well is as different as Lisp is from
| say conventional python.
| anthk wrote:
| Forth it's far easier than dc.
|
| On Lisp, exotic? it's damn easy. Haskell it's far worse.
| jonhohle wrote:
| It may suck for it, but it's better than a collection of
| random scripts and commands baked into CI configuration that
| evolve to become unrunnable in normal dev environments.
| paulddraper wrote:
| It works fine for PHONY targets.
|
| But most people don't realize in many cases they can do better
| than that.
| kiitos wrote:
| Consolidation of .PHONY targets is an anti-feature, the .PHONY
| decl is supposed to be adjacent to its target...
| teo_zero wrote:
| If only it accepted POSIX syntax...
___________________________________________________________________
(page generated 2025-06-22 23:00 UTC)