Thread (33 messages) flat view 33 messages, 6 authors, 2021-08-18

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

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-07-01 13:38:49

On Wed, Jun 30 2021, Felipe Contreras wrote:
Ævar Arnfjörð Bjarmason wrote:
quoted
On Mon, Jun 28 2021, Junio C Hamano wrote:
quoted
quoted
I do not see a point in complicating the build procedure to avoid
using it.
I'd really understand your and Jeff's concerns if I was proposing some
really complex workaround, but it's just extending & making consistent
the "mv" dance we already use for 1/2 our rules already.
I'm not entirely sure what's going on here. We have agreed that
.DELETE_ON_ERROR and the "mv" dance are orthogonal. So the patch to use
.DELETE_ON_ERROR can move forward, while the "mv" dance can be discussed
later.

Like Junio and Jeff, I don't see much value in the "mv" dance, but that
doesn't mean I want it gone. On the contrary, I would to try a scenario
in which it's usefull.

But that is *orthogonal*. Leave that for another discussion.
Yes, this whole sub-thread is just a side-discussion about a
change-not-in-this-series, which started out as a reference to a larger
series I carved this more narrow change from.
quoted
Even if you don't care about the end result or making git easier to hack
on for people who don't share your setup,
I don't know about Junio, I do want to make git easier to hack for
people that don't share my setup, but I would like to know what that
setup is.
I think all of this is covered in detail upthread.
quoted
I'd think that making those rules consistent across the board makes
things less complex, not more.
I don't agree with that. Consistency is just one of the many factors we
have to consider. Even if 90% of instances in the documentation said
"fast forward", that doesn't necessarily mean we should convert the
remaining 10% away from "fast-foward".

First we need to decide what is the end-goal we want to reach, and then
we can go for consistency.

But again, this is orthogonal to this patch, isn't it?
*nod*. I think for build rules it's easier to reason about them if all
of them e.g. do "$(RM) $@" at the start followed by "mv $@ $@+" at the
end, than wondering if the differences are accidental or intentional (in
most cases they're just a historical accident).q
quoted
Anyway, let's not discussed this forever. We're clearly getting
nowhere. Just for the record I'm quite miffed about the bar for "I don't
care about this area/platform/use-case, but this person actively sending
me patches in the area says it's helpful to send more patches" is so
low.
I don't think it's quite like that. Skepticism doesn't mean disapproval.

I for one are skeptic of the possitive value of the "mv" dance, but I
wouldn't be surprised in the least if you showed the value in 4 lines of
code. I just haven't seen them yet.

Once again... That's orthogonal to this patch.
*Nod*, as noted covered upthread.
quoted
Maybe that's all worth it, and I'd be willing to take the Windows devs
at their word that dealing with the make dependency was really *that*
painful. But compare that to carrying a few lines of "mv $@+ $@" to, I
daresay, make the same or larger relative improvement on AIX.
Oh I don't trust them at all. I did maintain some Windows installers for
years, and with a couple of tricks I had no problem building them with
plain Makefiles, with much more complex dependencies.

I'm fairly certain I could make git build for Windows with plain
Makefiles... But one controversy at a time.
Yeah, I think (from memory of reading the relevant threads) it's some
combinatin of "the dependency is large & painful" and "it's a bit
slower". I've found it hard in the past to get accurate estimates of
what's "slow" from our resident Windows maintainer:) Per:
https://lore.kernel.org/git/875z1lz6wl.fsf@evledraar.gmail.com/ (local)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help