git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Jul 1, 2021, 13:34 UTC
Message-ID
<87tulecfx7.fsf@evledraar.gmail.com>
In-Reply-To
<60dd3c92ef44b_174a220836@natae.notmuch>
On Wed, Jun 30 2021, Felipe Contreras wrote:
Show 20 quoted lines
> Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Jun 28 2021, Junio C Hamano wrote:
>
>> > 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.

Show 6 quoted lines
>> 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.
Show 12 quoted lines
>> 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

Show 13 quoted lines
>> 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.
Show 11 quoted lines
>> 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/

Previous: Felipe ContrerasNext: Felipe Contreras
Message 16 of 35 in “Makefile: add and use the ".DELETE_ON_ERROR" flag”
  1. Makefile: add and use the ".DELETE_ON_ERROR" flagÆvar Arnfjörð Bjarmason, Jun 22, 2021
  2. Taylor BlauJun 22, 2021
  3. Ævar Arnfjörð BjarmasonJun 22, 2021
  4. Jeff KingJun 22, 2021
  5. Ævar Arnfjörð BjarmasonJun 23, 2021
  6. Jeff KingJun 23, 2021
  7. Ævar Arnfjörð BjarmasonJun 24, 2021
  8. Jeff KingJun 24, 2021
  9. Ævar Arnfjörð BjarmasonJun 25, 2021
  10. Jeff KingJun 29, 2021
  11. Junio C HamanoJun 29, 2021
  12. Ævar Arnfjörð BjarmasonJun 29, 2021
  13. Junio C HamanoJun 29, 2021
  14. Jeff KingJun 30, 2021
  15. Felipe ContrerasJul 1, 2021
  16. Ævar Arnfjörð BjarmasonJul 1, 2021
  17. Felipe ContrerasJul 3, 2021
  18. Ævar Arnfjörð BjarmasonJul 3, 2021
  19. Felipe ContrerasJul 3, 2021
  20. Felipe ContrerasJun 23, 2021
  21. Felipe ContrerasJun 23, 2021
  22. Felipe ContrerasJun 23, 2021
  23. Ævar Arnfjörð BjarmasonJun 23, 2021
  24. Felipe ContrerasJun 23, 2021
  25. Ævar Arnfjörð BjarmasonJun 29, 2021
  26. Felipe ContrerasJul 1, 2021
  27. Felipe ContrerasJun 23, 2021
  28. Ævar Arnfjörð BjarmasonJun 23, 2021
  29. Felipe ContrerasJun 23, 2021
  30. Ævar Arnfjörð BjarmasonJun 29, 2021
  31. Felipe ContrerasJul 1, 2021
  32. Makefile: add and use the ".DELETE_ON_ERROR" flagÆvar Arnfjörð Bjarmason, Jun 29, 2021
  33. Makefile: remove archives before manipulating them with 'ar'SZEDER Gábor, Aug 18, 2021
  34. Junio C HamanoAug 19, 2021
  35. Ævar Arnfjörð BjarmasonSep 1, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.