On Wed, Jun 23 2021, Felipe Contreras wrote: > Ævar Arnfjörð Bjarmason wrote: >> As in db10fc6c09f this allows us to remove patterns of removing >> leftover $@ files at the start of rules, since previous failing runs >> of the Makefile won't have left those littered around anymore. >> >> I'm not as confident that we should be replacing the "mv $@+ $@" >> pattern entirely, since that means that external programs or one of >> our other Makefiles might race and get partial content. > > The reason I did it in db10fc6c09 is because both asciidoctor and > asciidoc should deal with temporary files by themselves (like gcc). If > you interrupt the build nothing gets generated. If you interrupt the build default make behavior without .DELETE_ON_ERROR kicks in. My gcc 8.3.0 just does an unlink()/openat(..., O_RDWR|O_CREAT|O_TRUNC) dance followed by chmod() when I do e.g.: gcc -o main main.c So no in-place atomic renaming, does yours do something different? But yes, some tools do this themselves, I think in general it's less annoying to deal with it yourself in a case like git's, because if they do it their idea of an in-tree tempfile may not jive with your .gitignore, so you'll racily see ghost files during build, or those files getting left behind if the tool hard dies. > However, other scripts like build-docdep.perl would indeed generate > partial output. > > In my opinion it's the scripts themselves that should be fixed, and not > the Makefile, *if* we care about this at all. I don't think default tool/make/*nix semantics are broken, I just think it's neat to do that rename dance yourself, it's a cheap way to guarantee that we always have working tools for use by other concurrent scripts. Many build systems or modes of running them don't care about that use-case.