4 ms·

I don't understand your complaints. > it's incumbent upon him to clearly state what failures I will avoid He does exactly that though? Here's a list of some o

I don't understand your complaints. > 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")

mayoff 4y ago
.DELETE_ON_ERROR is not sufficient. Some day your make process will be killed (due to a bug, OOM, kernel crash, power loss, whatever) while the recipe is running, thus having no chance to delete the broken output. 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 $@.tmp $< > mv $@.tmp $@ Once you adopt this strategy, .DELETE_ON_ERROR is irrelevant.
- dataflow 4y ago
  > .DELETE_ON_ERROR is not sufficient. Some day your make process will be killed (due to a bug, OOM, kernel crash, power loss, whatever) while the recipe is running, thus having no chance to delete the broken output. 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.

mayoff 4y ago

.DELETE_ON_ERROR is not sufficient. Some day your make process will be killed (due to a bug, OOM, kernel crash, power loss, whatever) while the recipe is running, thus having no chance to delete the broken output. 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 $@.tmp $< > mv $@.tmp $@ Once you adopt this strategy, .DELETE_ON_ERROR is irrelevant.

dataflow 4y ago
> .DELETE_ON_ERROR is not sufficient. Some day your make process will be killed (due to a bug, OOM, kernel crash, power loss, whatever) while the recipe is running, thus having no chance to delete the broken output. 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.