People hate Make because it doesn't define any conventions for its use. You can use it to do anything, but it does very little by default. This gives you a tremendous amount of freedom to declare exactly what it means to "build" an arbitrary component, but it also means you have to declare it yourself.

Many of the modern build tools move away from that. CMake, for instance, drops the ability to build arbitrary assemblages of files and focuses almost exclusively on giving you a nicely-constrained language for defining compilation targets and allowing you to support many different compilers.

Maven, Ivy, and it's ilk focus on declaring run-time dependencies and on some concept of a "build l lifecycle."

Having used all these systems, I find that there are things I need to do when running a build that I can easily do in Make, but which are encumbered significantly by other tools.

Make's syntax sucks, and it expects you to know a bunch of arcane stuff about how your project is built, but in exchange you get the ability to build literally anything.

In fact there is a lot of convention typically installed by default:

  $ make -pf /dev/null | wc -l
       359

Those suffix rules are enough for many projects, and a great example to follow if you need something different.

Better is very much in the eye of the beholder. I dislike most build tools, SCons included. I've found them all to be of varying degrees of meh to terrible.

But since Make is in use in so so many projects having good tutorials and material available is valuably to anyone who ends up needing to contribute to such an (open source) project.

I understand that people need resources to understand the Makefiles of existing projects, but I fear that tutorials might encourage people to use Make in new projects. Yes, I really want to extinguish Make. Other build tools are also "bad" but Make deserves a special place in hell.

Been using Make for decades, I don't see the problem. It works sufficiently well to be in use in a lot of my projects as a comfortable and productive environment. As with all 'tool X must die' conversations, one must always end with the only relevant conclusion that should be made: ymmv.

In this case, there are genuinly better options.

CMake, for example, is less arcane, and can also generate project files for visual studio.

I'd agree that make shouldn't really be the go-to choice for brand new projects. It's limitations can encircle new projects.

CMake generates makefiles, at least as I have used it, so you need to understand makefiles to debug any build problems.

It's true, but it has the benefit that your makefiles are now complient with every other cmake users makefiles, and not special snowflakes. That makes it more likely that someone has already had your problem and posted a turnkey solution.

CMake, less arcane? Surely you're jokin.

Have a look at the discussion at https://news.ycombinator.com/item?id=9945438

I like the look of redo or tup.

I was one of the folks that mentioned tup in that link. Allow me to take a moment and mention my support for it again. It is an incredibly simple build-system with a ton of advantages over make et al.

I use tup widely across my personal projects and I must say, it has dramatically simplified my dev life.

Oh man I wish I could love tup. That syntax is great, it cleans all by itself, and figures-out dependencies all by it self - even the source file often! But it was a total no-go when I tried on FreeBSD. Basically it does those awesome things by leveraging FUSE and makes all sorts of assumptions about how FUSE operates which are not true on FreeBSD. More over those assumptions would need to change as some of them are bugs and others are honest to goodness differences for good reason. So it boils down to, tup is just too clever sadly.

That's such a bummer! I'm sorry to hear that it doesn't work for FreeBSD! You should consider opening a bug about it; the devs seem pretty open and responsive. Maybe they'll get it fixed for you!

What are your specific complaints about make, and how does SCons fix them?

It is still better to have one kind-of-bad build tool, than hundreds of build tools that are slightly better. Every time you have to install new software and something goes wrong, you'd have to learn a new build tool!