> it's incumbent upon him to clearly state what failures I will avoid

He does exactly that though? Here's a list of some of them:

Rule: "Use a strict Bash mode"

Failure(s) avoided: "your build may keep executing even if there was a failure in one of the targets."

Rule: .ONESHELL

Failure(s) avoided: assignments failing to take effect on subsequent lines ("it lets you do things like loops, variable assignments and so on in bash")

Rule: .DELETE_ON_ERROR

Failure(s) avoided: "ensures the next time you run Make, it’ll properly re-run the failed rule, and guards against broken files"

Rule: MAKEFLAGS += --warn-undefined-variables

Failure(s) avoided: avoids silent misbehavior when a variable doesn't exist ("if you are referring to Make variables that don’t exist, that’s probably wrong and it’s good to get a warning")

I had this happen often enough (in a quite large system that farmed out compile jobs to a cluster) that now I always make my recipes write to a temporary file, and then rename the temp file to the actual target, e.g.

test.o: test.c > cc -o [email protected] $< > mv [email protected] $@

Once you adopt this strategy, .DELETE_ON_ERROR is irrelevant.

I agree, it's one reason Make itself sucks.

> I always make my recipes write to a temporary file, and then rename the temp file to the actual target

Then hopefully set the timestamp if you used some tool to generate it so it doesn't look out of date to Make. (Again, another deficiency of Make. I could list more.)

> Once you adopt this strategy, .DELETE_ON_ERROR is irrelevant.

Sure (well actually no, but that's next paragraph), but that strategy is only worth it for "serious" Makefiles. Ones you use in your work environment and all. For personal projects etc. it's not always worth the hassle of polluting the Makefile with boilerplate like that; it's much handier to put that one line.

But actually no, there's still a benefit: it saves disk space to delete incomplete output files. If your files are 4KiB you might not care, but if they're 4GiB then you might. And sure you can get around that by manually adding 'rm' in the beginning of every rule too, but why not use this instead while it's already there. It's one line and doesn't harm anything.

I was on the fence about posting this reply; after all the guidelines tell us to stay relevant to the material, but I do believe you have done that.

Not with me, unless you're talking about the difference between clear and unclear language.

I'm not bothered by language that some people seem to class as patronizing or like you know everything or whatever. When somebody is explaining something to me, I don't want them to explain it to me like I know it already. I want them to explain it to me like someone I've hired to explain things to me i.e. like they're the expert and I'm not.

If I think I know everything about make, there's no reason for me to have clicked on this other than an urge to seek out things that confirm my sense of self-worth, or to get upset about things that threaten it.

I agree, any claim that you should do XYZ should give a strong argument.

The article here does try to give very short arguments, to be fair. I leave unconvinced by many of them. For example, requiring bash means you can't use dash; dash is less capable but much faster.

I prefer arguments that walk through the key pros and cons. Longer, but in long run more useful.

Seems like dash would be fine for the author.

The author makes several convincing arguments and specifically lays out what failure modes are avoided for each recommendation. Honestly the title is completely out of step with the tone of the argument, which is a critique I can support.