Stop Copy-Pasting Makefiles. Make Already Has a Package Manager.

You’ve done it. I’ve done it. Every developer who’s ever touched GNU Make has done it. You write a beautiful, elegant make deploy target in one project — handles staging, runs migrations, tags the release — and then you open the next project’s Makefile and hit Ctrl+C, Ctrl+V like it’s 2009.

Copy-paste isn’t a workflow. It’s a confession that your tools have outgrown your system for managing them.

This is the dirty secret of Make. It’s everywhere. It’s on every Linux box, every CI runner, every dev container. It’s the one build tool that needs zero installation, zero dependencies, zero apologies. And yet, when you want to share a target between projects, you’re reduced to the same primitive ritual as a first-year intern: open file, select all, copy, paste, pray nothing breaks.

That’s where MKPM comes in. It’s a GNU Make Package Manager — yes, you read that correctly — and it does the one thing Make has never done: let you install, version, and reuse Makefile targets like they were npm packages.

The creator built it out of pure frustration. Same story as the rest of us: projects piled up, useful targets multiplied, and the copy-paste treadmill became unbearable. So they turned Make into something it was never designed to be — a script-sharing platform.

Here’s how it works: MKPM lets you declare dependencies on Makefile packages, pull them in, and use their targets as if you’d written them yourself. No more maintaining five copies of the same Docker build target across five repos. No more discovering a bug in your deploy script, fixing it in one place, and forgetting the other four.

The beauty of Make was always its simplicity. The tragedy of Make is that simplicity became a ceiling.

And this is where things get interesting — and uncomfortable. MKPM solves a real problem, no question. But it also introduces the exact thing that Make’s most devoted users have spent decades avoiding: a management layer. Dependencies. Version conflicts. The slow creep of complexity that turns a 20-line Makefile into something that needs its own documentation.

The contrarian question is obvious: if you’re adding a package manager to Make, are you still using Make? Or have you just reinvented the modern task runner with extra steps?

Tools like Just and Taskfile exist precisely because developers wanted Make’s ergonomics without its baggage. They’re purpose-built for script running, with clean syntax and no legacy cruft. MKPM takes the opposite bet: instead of replacing Make, it extends it. It says, ‘Make is already everywhere, already installed, already understood — let’s make it shareable instead of starting over.’

That’s either brilliant or delusional, and honestly, it might be both.

Every tool that survives long enough eventually becomes a platform for the thing it was never meant to do. That’s not a bug — that’s how infrastructure evolves.

If you’re a Make loyalist — someone who reaches for make before npm scripts, before package.json, before anything — MKPM is worth a serious look. It won’t change your day-to-day. But it might change your month-to-month, the next time you spin up a project and realize you don’t have to rebuild the same five targets from scratch.

If you’re already eyeing the exit, already experimenting with Just or Taskfile, MKPM is a fascinating case study in what happens when a 48-year-old tool refuses to die. It’s Make fighting back. Adding features. Adapting. Proving that ubiquity is its own form of momentum.

Will it work? Will developers embrace a package manager for a tool that was never meant to have one? Or will the complexity tax push more people toward purpose-built alternatives?

I don’t know. But I know this: the next time you copy-paste a Makefile target, you’ll feel it — that small, nagging voice saying there has to be a better way. Now there is. Whether it’s the right way is up to you.