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)