On Tue, Mar 30, 2021 at 11:36:06AM -0700, Junio C Hamano wrote:
> > 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
