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

https://github.com/EbodShojaei/bake

by rainmans • 1 year ago

227 83 1 year ago

github.com

jtwaleson• 1 year ago

Nice, would be good to package this as a https://pre-commit.com/ hook.

foma-roje• 1 year ago

It really doesn’t have to be complicated for it to be useful. Plenty thanks for sharing this.

x3n0ph3n3• 1 year ago

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• 1 year ago

You can pass arguments via the command line (it is, after all, a CLI tool): https://stackoverflow.com/questions/2826029/passing-addition...

lmz2• 1 year ago

I mean there's really not much difference between "VAR=val make x" and "make x VAR=val" now is there?

hiAndrewQuinn• 1 year ago

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• 1 year ago

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• 1 year ago

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.

georgyo• 1 year ago

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• 1 year ago

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.

zelphirkalt2• 1 year ago

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.

zelphirkalt2• 1 year ago

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• 1 year ago

Make is in POSIX, so it's generally available. Same reason people write shell scripts (even if the scripts are not generally POSIX-only).

bshacklett3• 1 year ago

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.

PhilipRoman• 1 year ago

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• 1 year ago

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• 1 year ago

Make is not language agnostic; it has implicit rules for compiling C.

dima552• 1 year ago

Look at "remake": a drop-in fork of GNU make, with an interactive debugger.

aboardRat4• 1 year ago

Because make is a prolog in disguise.

gjvc• 1 year ago

you don't do it naked, you write and use wrapper scripts to make it ergonomic

motorest2• 1 year ago

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-• 1 year ago

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.

Crier10022• 1 year ago

ive always wanted this. im going to give it a go!

does this happen to support IDE like vscode?

antonhag• 1 year ago

From the readme:

  VSCode Extension
    1. Open VSCode
    2. Go to Extensions (Ctrl+Shift+X)
    3. Search for "mbake Makefile Formatter"
    4. Click Install

Crier10022• 1 year ago

thanks! apologies i was on mobile and missed this. im excited to try it out

s4i• 1 year ago

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.

pjmlp2• 1 year ago

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• 1 year ago

It wouldn't have been Matthias Andrée'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• 1 year ago

ewwww. consolidated phony lines. everyone knows these should be right before each rule declaration.

leetrout2• 1 year ago

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• 1 year ago

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• 1 year ago

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• 1 year ago

That doesn't sound any different than it is for any other programming language, but many people prefer automatic formatting anyways.

kseistrup• 1 year ago

Here's an AUR package:

https://aur.archlinux.org/packages/python-bake-git

eabeezxjc• 1 year ago

simple use rake

notnmeyer• 1 year ago

or any other task runner

rurban• 1 year ago

Differences to checkmake, the older Makefile's linter and formatter?

rednafi4• 1 year ago

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.

kiitos5• 1 year ago

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...

rednafi4• 1 year ago

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.

vachina• 1 year ago

You only have to install pip once. It’s a one-time set and forget operation. And with conda, it’s even easier with just click and install.

callc• 1 year ago

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...

TZubiri2• 1 year ago

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.

blks• 1 year ago

it’s harder to distribute software written in python via eg package manager compared to compilable languages.

seanwilson• 1 year ago

Anyone else not bother maintaining a list of .PHONY targets? Always felt like a chore that adds noise for a rare edge case.

leetrout2• 1 year ago

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...

CableNinja• 1 year ago

I use a shell command as .PHONY, to keep it always synced. the command looks through the makefile, and then outputs the targets for the line.

I also use a similar pattern to provide a `help` target, which shows all targets, and a blurb about its purpose

jbverschoor2• 1 year ago

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• 1 year ago

The nice thing about make is that is ubiquitous, and that it offers nice things out of the box.

jbverschoor2• 1 year ago

This is so unfortunate about these ubiquitous tools.

At a certain point we seem to have stopped adding tools to POSIX.

Does anyone know why exactly?

dima552• 1 year ago

Right. It kinda sucks for that purpose too, which gives Make a bad name.

kristopolous• 1 year ago

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.

jonhohle• 1 year ago

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• 1 year ago

It works fine for PHONY targets.

But most people don’t realize in many cases they can do better than that.

kiitos5• 1 year ago

Consolidation of .PHONY targets is an anti-feature, the .PHONY decl is supposed to be adjacent to its target...

worthless-trash2• 1 year ago

Possible opinion detected. Explain why.

chrismorgan• 1 year ago

Look at https://github.com/EbodShojaei/bake#basic-formatting. It starts with a horribly contrived example¹ including this²:

  .PHONY: clean
  all: $(TARGET)
      $(CC) $(CFLAGS) -o $@ $^

  .PHONY: install
  clean:
      rm -f *.o

And changes it to this with a consolidated .PHONY, but still no install target. Surely it should complain “there is no install target, what are you marking it as phoney³ for?”

  .PHONY: all clean install

  all: $(TARGET)
      $(CC) $(CFLAGS) -o $@ $^

  clean:
      rm -f *.o

I will not say that this way of writing it is unreasonable; users unfamiliar with the available targets can benefit from such a thing up the top (though in practice there’s normally a block of other stuff first, and other ways of achieving it). But this is also a reasonable way of writing it, with strong advantages of its own:

  .PHONY: all
  all: $(TARGET)
      $(CC) $(CFLAGS) -o $@ $^

  .PHONY: clean
  clean:
      rm -f *.o

  .PHONY: install
  # Um… where’s the `install:` line?

Treating .PHONY as more an inline attribute like this rather than a target of its own makes it much more obvious that the install target is missing, and makes desynchronisation of .PHONY and the actual targets much less likely.

—⁂—

¹ The first atrocity is that it’s not even a legal makefile: barring a .RECIPEPREFIX override, recipes must be indented by one tab. Running make with this file produces “Makefile:10: ** missing separator. Stop.” Taking invalid code and making it valid is not the domain of a linter or formatter. The Markdown is also abysmal because it doesn’t use tabs, but rather a single space in the output. Given that tabs are structural in makefiles, this is an astonishing lapse.

The second atrocity is the mismatching of .PHONY targets, despite joining the lines (by not having a blank line after the .PHONY line), which is completely unrealistic. Or at least I find it so.

² I have normalised whitespace so we can focus on the .PHONY changes. Assume tabs are where they need to be. Unfortunately HN hates interesting whitespace.

³ Ah, the number of times I’ve written .PHONEY… stupid americentric software.

teo_zero• 1 year ago

If only it accepted POSIX syntax...

AdieuToLogic• 1 year ago

Speaking of make...

A while back I attended an open-source conference (which was a lot of fun). After the presentations, people would "set up shop" at tables and jam on whatever was their fancy.

One evening there was a person using make as a SAT solver[0]. That blew my mind to be honest. I had used make for years as a build tool and never thought of it in that problem space.

This memory isn't relevant to this project. I was just reminded of the experience is all.

0 - https://en.wikipedia.org/wiki/SAT_solver

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

Related Stories