Re: [PATCH] Makefile: add and use the ".DELETE_ON_ERROR" flag

From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH] Makefile: add and use the ".DELETE_ON_ERROR" flag
Date: Wed, 23 Jun 2021 21:45:04 +0200	[thread overview]
Message-ID: <87tulo1hs4.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <60d384ecd5ad3_4290208c@natae.notmuch>

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.