Make vs. CMake: A Love Letter to Simplicity (and a Mild Complaint About Modernity)

There was a time when build systems had the decency to be understood by humans.

You opened a Makefile. You read it. You nodded. You fixed it. Done.

No ceremony. No abstraction layers. No existential crisis.

Just rules, dependencies, and a quiet sense that the machine was doing exactly what you told it to do—nothing more, nothing less.


The Case for Make: Brutal Honesty

Make has one defining virtue: what you see is what you get.

A rule says:

foo.o: foo.c
    gcc -c foo.c

And that is precisely what happens. There is no hidden state machine, no meta-language interpreting another meta-language. It is gloriously literal.

Pros:

  • Readable: A competent developer can understand a Makefile in minutes.
  • Transparent: No magic. If something breaks, you trace it directly.
  • Portable enough: Works anywhere vaguely Unix-like.
  • Minimal overhead: You don’t “configure” your build system—you write it.

Cons:

  • Manual work: You are the build system.
  • Scaling pain: Large projects become forests of includes and conventions.
  • Platform quirks: Cross-platform builds are… character-building.

Still, for many of us, that’s the point. You stay in control. You own the build.


The Case for CMake: Ambition Meets Reality

CMake enters with a noble promise: write once, build anywhere.

And to be fair—it delivers. Eventually.

Pros:

  • Cross-platform abstraction: Windows, Linux, macOS—all handled.
  • Out-of-source builds: Clean separation between code and artifacts.
  • Ecosystem integration: IDEs, package managers, CI systems—CMake speaks their language.
  • Scalability: Large, multi-component systems benefit from structure.

Now the other side.

Cons:

  • Unreadable DSL: A language that looks like code, behaves like a macro processor, and documents like folklore.
  • Indirection everywhere: Variables that expand into variables that expand into commands you didn’t write.
  • Debugging pain: When it fails, you’re spelunking through layers of generated logic.
  • Cognitive load: You don’t read a CMake project—you interpret it.

A simple question—“how is this file compiled?”—can turn into a small archaeological dig.


The Cultural Divide

This isn’t just tooling. It’s philosophy.

  • Make says: You are responsible. Be precise.
  • CMake says: Let me handle that for you.
    (And occasionally does. And occasionally… doesn’t.)

Old-timers prefer Make not because it’s perfect—but because it’s honest.
It doesn’t pretend to be smarter than you.

CMake, on the other hand, tries very hard to be helpful. And like many helpful systems, it sometimes becomes helpful in ways you didn’t ask for.


A Fair Conclusion (Reluctantly)

CMake wins in:

  • Large, cross-platform projects
  • Teams with mixed environments
  • Integration-heavy ecosystems

Make wins in:

  • Clarity
  • Control
  • Small-to-medium projects
  • Sanity

Final Thought

If Make is a well-organized toolbox, CMake is a fully automated workshop with a user manual written in riddles.

Both build your project.

One lets you understand it.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.