Re: [PATCH v2 4/5] Makefile: add the ".DELETE_ON_ERROR" flag

From: Jeff King <peff@peff.net>
Date: Mar 31, 2021, 06:58 UTC
Message-ID: <YGQdpkHAcFR/zNOx@coredump.intra.peff.net>
In-Reply-To: <xmqqft0cebft.fsf@gitster.g>

On Tue, Mar 30, 2021 at 11:36:06AM -0700, Junio C Hamano wrote:

Show 16 quoted lines

> > Yes, I think it's fine to treat it as "nice if we have it, but OK
> > otherwise". But also, .DELETE_ON_ERROR first shows up in the GNU make
> > git repository in version 3.71.5 from 1994. So I think we can probably
> > just assume it's everywhere.
> 
> OK.  That raises my hopes up that we may be able to simplify things
> like this
> 
>     config-list.h:
>             $(QUIET_GEN)$(SHELL_PATH) ./generate-configlist.sh \
>                     >$@+ && mv $@+ $@
> 
> into
> 
>     config-list.h:
>             $(QUIET_GEN)$(SHELL_PATH) ./generate-configlist.sh >$@

Yes, I think .DELETE_ON_ERROR would accomplish roughly the same thing. Though note that it's essentially a "rollback" strategy. We create the broken file, realize there was an error, and the roll it back (as opposed to the "mv" strategy, which confirms everything is good before committing it into place). This is worse than a "commit" strategy in a few ways:

  - somebody else may racily see the broken state. I'm not too concerned
    with this, and from the rest of the thread I don't think you are
    either.

  - we may be left in the broken state if the rollback fails. Plausible
    reasons are: somebody kills "make" (I'd hope on the obvious ^C that
    it catches the signal and deletes before exiting), bug in make,
    transient OS error, power failure, etc.

I don't know how paranoid we want to be about this, especially the latter. My general inclination is to prefer "commit" systems as more robust, but it is just a Makefile.

-Peff