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

From: Felipe Contreras <felipe.contreras@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"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 15:52:09 -0500	[thread overview]
Message-ID: <60d39ef9a8071_429020896@natae.notmuch> (raw)
In-Reply-To: <87o8bw1hc5.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason wrote:
> 
> On Wed, Jun 23 2021, Felipe Contreras wrote:
> 
> > Ævar Arnfjörð Bjarmason wrote:
> >> @@ -2243,7 +2253,6 @@ SCRIPT_DEFINES = $(SHELL_PATH_SQ):$(DIFF_SQ):$(GIT_VERSION):\
> >>  	$(gitwebdir_SQ):$(PERL_PATH_SQ):$(SANE_TEXT_GREP):$(PAGER_ENV):\
> >>  	$(perllibdir_SQ)
> >>  define cmd_munge_script
> >> -$(RM) $@ $@+ && \
> >>  sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
> >>      -e 's|@SHELL_PATH@|$(SHELL_PATH_SQ)|' \
> >>      -e 's|@@DIFF@@|$(DIFF_SQ)|' \
> >
> > Any reason why the same isn't done for the $(BUILT_INS) target?
> >
> >> @@ -2514,7 +2522,6 @@ endif
> >>  ifeq ($(GENERATE_COMPILATION_DATABASE),yes)
> >>  all:: compile_commands.json
> >>  compile_commands.json:
> >> -	@$(RM) $@
> >>  	$(QUIET_GEN)sed -e '1s/^/[/' -e '$$s/,$$/]/' $(compdb_dir)/*.o.json > $@+
> >>  	@if test -s $@+; then mv $@+ $@; else $(RM) $@+; fi
> >>  endif
> >
> > What about these?
> >
> >   $(REMOTE_CURL_ALIASES):
> 
> Uses a chain of ln/ln -s/cp, would need to add "-f" flags.

Why? Isn't "x && a || b || c" the same as "a || b || c" if x is always true?

> >   $(LIB_FILE):
> 
> Can we rely on $(AR) happily clobbering things everywhere? Not knowing
> is why I skipped it.

We have c (create) in ARFLAGS, so presumably yes.

> >   $(ETAGS_TARGET):
> >   tags:
> >   cscope:
> 
> Addressed in the related:
> https://lore.kernel.org/git/YNH+zsXDnRsT3uvZ@nand.local/T/#t

I think ideally this patch should remove the $(RM) and the other patch
should focus on the rest of the changes, but given the difficulty of
landing chained patch series in git I understand the decision to clump
them together.

Cheers.

-- 
Felipe Contreras