> I’d be interested in hearing about the problems Make has caused you

The main problem that kept burning me was that I'd have a "dirty" build when I thought I had a clean one or an incorrect one when I thought I had a correct one. It was super hard to get the dependency graph correct because developers were creating files left and right but would only update the Makefile just enough to get it building (and forget to add new header files to the list of headers, etc) so I had little confidence in incremental builds and was always building from the ground up.

CMake's generated build systems always have correct dependency graphs (i.e. it will only rebuild the bare minimum when you touch a given file) and I've always had complete confidence that my build is clean (since I just created a fresh directory) and that my incremental builds are correct.

> and forget to add new header files to the list of headers

This is why gcc/clang have the option to generate Makefiles for the header dependencies for you. Maintaining these yourself is a hopeless effort.

That makes a lot of sense. Setting up automatic dependency detection is what finally made Make click for me, and it’s not the most straightforward process to get right. How does CMake detect the files that a given product depends on; does it have language-specific dependency detection or something else?

> How does CMake detect the files that a given product depends on; does it have language-specific dependency detection or something else?

Well actually, CMake is a build system generator - and the default build system it generates is Unix Makefiles. So I assume CMake generates Makefiles with the appropriate automatic dependency detection baked in, I'm not sure.

The important part was that it eliminated human error on our team and we haven't had dependency graph problems since.

CMake has its own dependency scanner for C/C++. Look for a file 'depend.make' and you'll see the header dependencies that CMake has detected, minus the headers that CMake thinks are system headers.

Sometimes you can make mistakes which delete files, but you should keep development files backed up in some capacity. Still, spot the bug here:

    AS_SRC = main.S util.s
    OBJ = $(AS_SRC: .S=.o)
    [...]
    clean:
        rm -f $(OBJ)

The source files with a lower-case extension aren’t getting their file names translated and are passed straight through into OBJ unchanged.

Granted, knowing that there’s an error here helped greatly in spotting it; there’s a good chance I would have run the incorrect makefile at least once before investigating.

Whatever the bug, git reset is the solution.

Not the original parent, but the problem I've noticed most recently with make is when people use it to orchestrate building/running docker containers. I've seen several cases where containers will be pulled/rebuilt on every invocation (even if they don't need to be) because there's no file based dependency to indicate they're actually up to date. While docker's layer caching helps with this, it still can add a fair bit of time in some cases.

I've worked around that in the past by creating empty "target files" that are created when a given target is built and which dependencies rely on, but it's not a perfect solution.

I've looked around for a make alternative, but although I like rake, I don't really use Ruby these days, and so dealing with RVM/rbenv and whatnot is sort of a pain and not worth the effort over make.