Be Aware of the Makefile Effect

Yeah, I've always been mystified by the idea that writing a new Makefile is some kind of wizardly mystery. Make has its design flaws, for sure, but how hard is it really to write this?

    CFLAGS = -std=gnu99 -Wall

    all: foo
    clean:
        $(RM) foo *.o

    foo: foo_main.o foolib.o
        $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@

(Except with tabs, which HN doesn't allow.)

I haven't tested what I just typed above, but I'm reasonably sure that if I biffed it in a way that makes it nonfunctional, it will be obvious how to correct the problem.

I mean, not that you can't do better than that (I'm pretty sure anyone experienced can see some problems!), or that there aren't tricky and annoying tradeoffs, but it just doesn't seem like a big activation barrier the way people sometimes make it out to be?

Maybe those people just need to spend an afternoon once in their life working through a basic make tutorial? Maybe not the first time they work on a project using make, but, maybe, after the fifth or sixth project when they realize that this somewhat primitive inference engine is going to be something they interact with daily for years? At some point you're getting into "lead a horse to water" or "teach a man to fish" territory. There's a limit to how much you can empower someone who's sabotaging themself.

There's a slightly less minimal example in https://www.gnu.org/software/make/manual/html_node/Simple-Ma... with a full explanation. You can read it in a few minutes, but of course you have to experiment to actually learn it. The whole GNU Make 4.4.1 manual in PDF form is only 229 pages, so you can read it after dinner one night, or on your commute on the train over the course of a few days. And then you'll know the complete rules of the game.

Auto-generated Makefiles that CMake and Autotools produce really leave a bad impression on how complex Makefiles need to be.

Yeah, I guess trying to read the output of gcc -O -S would make assembly language seem pretty overwhelming, too.

Specifically, any generated makefile that refuses to take advantage of GNU make is necessarily going to be horrible.

BSD make is ... viable I guess, but only really worth it if you're already in the ecosystem - and even then I can't guarantee you won't hit one of its silly limitations.

Good news, you can change the output then! And for as much as you might not like its generated Makefiles, I assert that $(cmake -G Ninja) is 100,000,000x more "wtf" than -G Makefiles

I disagree about the autotools ones, I find them very sane although autotools itself can die in a rotting dumpster out back. And take m4 with it.

Yeah, m4 is powerful in its way, and has an extraordinary strength-to-weight ratio (check out the implementation in Software Tools in Pascal) but ultimately I think it turned out to be a mistake. Make, by contrast, turned out to be a good idea despite its flaws.

You can drop the last line---make already knows the incantations to compile a C file.

I did drop the lines you're thinking of. The last line is to specify which .o files go into the executable.

Ninja isn't really a reasonable comparison to make. Ninja is explicitly not designed to be human authored like Makefiles are. Ninja is designed to be an output from some build system generator like CMake and doesn't make affordances for humans as it's intended for machine generation and machine consumption so it can be _very_ fast (which it is).