Stats for nerds
3recommend
8mentions
8people
2009–2023years
38% recommend63% neutral
Mentions per year
What Hacker News says
- Before a couple of years ago, I had never written a Makefile in my life.
I ended up using Make after experiencing web project builder merry-go-round du jour of Grunt, Gulp, npm/yarn scripts, WebPack, etc.
Of course I had read all of the Make FUD… but like almost all things in computing (Vim vs. Emacs, tabs vs. spaces, Mac vs. Windows) you can't take it too seriously.
For me, similarly to when I went through several editors before I discovered Vim, Make has been around long enough and people have used it to address the hairiest build/dependency issues that many of the new tools have yet to address.
Let me address a few common issues.
IMHO the syntax isn't that bad. Like almost any programming language, you can write a clean, well-documented Makefile following best practices or you can slap something together with no planning and have an indecipherable page of junk.
And like many languages, many folks never learn to write Makefiles properly. I get it—most Makefiles in the wild are close to unreadable and are mostly undocumented.
And because Make has been around since the '70s, there's lots of hard-earned wisdom in blog posts and forums readily available going back decades.
O’Reilly's book "Managing Projects with GNU Make" (3rd edition) does a great job at getting someone up and running with Make. And the online documentation [1] is also quite good.
But the most important thing is I'm much more productive using Make instead of messing around with the various JavaScript build tools and their plugins. It's easy to integrate JavaScript, command line, Ruby, etc. tools with Make to get my projects built, linted, tested, packaged and deployed.
And having native support for Make in Vim/Neovim [2] is just the cherry on top. And it's still under active development [3] with bug fixes and new features.
Perhaps the best thing about Make: there's no dependency graph/build web project issue it can't handle. Writing clean, readable and well-documented may take a little more effort but it's worth it IMHO.
[1]: https://www.gnu.org/software/make/
- Managing Projects with GNU Make, 3rd Edition
https://www.oreilly.com/library/view/managing-projects-with/...
O'Reilly is free via my public library. Yours might have the same
- Managing Projects with GNU Make by O'Reilly is a good start. Make is much less mystifying if you get through all of its quirks. Make is not great in many ways (significant tabs are annoying, for example), but it's no SBT.
- My ideal approach to Gradle would be reading every User Manual [1] starting from v0.7 [2]. But not even an entire workweek is enough for that kind of meditative study.
As a comparison, building Java with make:
https://www.oreilly.com/openbook/make3/book/ch09.pdf [PDF]
From Managing Projects with GNU Make 3e (2004) by Robert Mecklenburg
- I'm not writing C. so I'm not sure what you mean, I mentioned ./configure as a solution to a problem because it was obviously a big enough problem;
To go into issues though:
Make itself executes by default with `sh` which is wildly different between platforms.
Even if you write portable enough shell; Paths are still incompatible between OS's and distros.
You still must ship your tools, which is a direct contradition of what is mentioned.
In fact; I just googled it and this chapter from Managing Projects with GNU Make; talks about the issues in making Make (GNU Make, as opposed to BSD Make, which is different enough to have broken my things!): portable
https://www.oreilly.com/library/view/managing-projects-with/...
- I am definitely amazed and grateful like others by the work involved in writing this book. The attention to detail is visible from the first parts of the README. Clear explanations for everything.
I am also a sucker for clean written Makefiles. I have "Managing Projects with GNU Make" book that I keep in my to-read list (shamefully putting reading it off). Checking out the Makefile in the repository was a delight.
