All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Taylor Blau <me@ttaylorr.com>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Felipe Contreras <felipe.contreras@gmail.com>
Subject: Re: [PATCH] Makefile: add and use the ".DELETE_ON_ERROR" flag
Date: Tue, 22 Jun 2021 15:17:45 -0400	[thread overview]
Message-ID: <YNI3WVu5SK7pHI7T@coredump.intra.peff.net> (raw)
In-Reply-To: <8735t93h0u.fsf@evledraar.gmail.com>

On Tue, Jun 22, 2021 at 07:34:13PM +0200, Ævar Arnfjörð Bjarmason wrote:

> > That makes me a little sad, but it does leave us with a much cleaner
> > Makefile as a result. So, I'm not really sure how to feel about it. I
> > think in general I would be happy overall to see this picked up.
> >
> > [1]: https://lore.kernel.org/git/YGQdpkHAcFR%2FzNOx@coredump.intra.peff.net/
> 
> Yes, it makes me sad too, but as noted above I think you're right about
> the general case, and so is Jeff in that E-Mail you linked, but it
> doesn't apply to these patches, or my earlier patches.
> 
> I'd like us to always have a working binary, but from my understanding
> of Jeff and Junio's position on it it's something they'd like to
> actively prevent, see the discussion around my earlier series.
> 
> I.e. from what I gather they view this "your thing is clobbered as it
> builds" as a feature. I.e. it serves to throw a monkey wrench into any
> use of git that may overlap with said build, and they think that's a
> feature.

Just to be clear, I would be happy to drop the "oops, the tests barf if
you recompile halfway through" feature away if it made things more
robust overall (i.e., if we always did an atomic rename-into-place). I
just consider it the fact that we do clobber to be an accidental feature
that is not really worth "fixing". But if we care about "oops, make was
interrupted and now you have a stale build artifact with a bogus
timestamp" type of robustness, and "the tests barf" goes away as a side
effect, I won't complain.

I'd like it a lot more if we didn't have to add "mv $@+ $@" to every
rule to get there. In some other projects I've worked on, compilation
happens with a script, like:

  %.o: %.c
	./compile $@

and then that "compile" script is generated by the Makefile, and encodes
all of the dependencies of what's in $(CC), $(CFLAGS), and so on (we'd
probably have an update-if-changed rule like we do for GIT-CFLAGS).

And it also becomes an easy single spot to do that kind of "let's
replaced the output atomically" trick.

That's a pretty big departure from our current Makefile style, though.
And I don't feel like it buys us a lot. Having a pretty generic and
typical Makefile is nice for people coming to the project (I have
noticed that most people are not well versed in "make" arcana).

-Peff

  reply	other threads:[~2021-06-22 19:17 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22 14:13 [PATCH] Makefile: add and use the ".DELETE_ON_ERROR" flag Ævar Arnfjörð Bjarmason
2021-06-22 15:27 ` Taylor Blau
2021-06-22 17:34   ` Ævar Arnfjörð Bjarmason
2021-06-22 19:17     ` Jeff King [this message]
2021-06-23 19:54       ` Ævar Arnfjörð Bjarmason
2021-06-23 22:21         ` Jeff King
2021-06-24 13:53           ` Ævar Arnfjörð Bjarmason
2021-06-24 14:49             ` Jeff King
2021-06-25  9:49               ` Ævar Arnfjörð Bjarmason
2021-06-29  2:26                 ` Jeff King
2021-06-29  6:19                   ` Junio C Hamano
2021-06-29  7:39                     ` Ævar Arnfjörð Bjarmason
2021-06-29 21:38                       ` Junio C Hamano
2021-06-30  2:23                       ` Jeff King
2021-07-01  3:54                       ` Felipe Contreras
2021-07-01 13:34                         ` Ævar Arnfjörð Bjarmason
2021-07-03  0:41                           ` Felipe Contreras
2021-07-03 12:31                             ` Ævar Arnfjörð Bjarmason
2021-07-03 18:42                               ` Felipe Contreras
2021-06-23 19:15     ` Felipe Contreras
2021-06-23 19:09   ` Felipe Contreras
2021-06-23 19:01 ` Felipe Contreras
2021-06-23 19:45   ` Ævar Arnfjörð Bjarmason
2021-06-23 20:32     ` Felipe Contreras
2021-06-29  7:29       ` Ævar Arnfjörð Bjarmason
2021-07-01  3:06         ` Felipe Contreras
2021-06-23 19:21 ` Felipe Contreras
2021-06-23 19:59   ` Ævar Arnfjörð Bjarmason
2021-06-23 20:52     ` Felipe Contreras
2021-06-29  8:17       ` Ævar Arnfjörð Bjarmason
2021-07-01  3:19         ` Felipe Contreras
2021-06-29  8:44 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2021-08-18 21:36   ` [PATCH] Makefile: remove archives before manipulating them with 'ar' SZEDER Gábor
2021-08-19 23:39     ` Junio C Hamano
2021-09-01 17:06       ` Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YNI3WVu5SK7pHI7T@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.