From: Felipe Contreras <felipe.contreras@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Felipe Contreras" <felipe.contreras@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
Taylor Blau <me@ttaylorr.com>,
git@vger.kernel.org
Subject: Re: [PATCH] Makefile: add and use the ".DELETE_ON_ERROR" flag
Date: Sat, 03 Jul 2021 13:42:23 -0500 [thread overview]
Message-ID: <60e0af8f1636d_2f720865@natae.notmuch> (raw)
In-Reply-To: <87k0m78sc7.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Jul 02 2021, Felipe Contreras wrote:
>
> > Ævar Arnfjörð Bjarmason wrote:
> >> On Wed, Jun 30 2021, Felipe Contreras wrote:
> >> > Ævar Arnfjörð Bjarmason wrote:
> >>
> >> >> 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.
> >
> > From [1] I understand some systems have a problem clobbering a binary
> > that is being run. So if you are running a test that is using a binary
> > that you are rebuilding at the same time, you get an error.
> >
> > OK.
> >
> > I still don't see why anyone would want to rebuild the binary in the
> > middle of running tests. The result of the tests is only meaningful for
> > a particular build. This is what I don't get. I get that you want to do
> > this, what I don't get is *why*.
>
> This is mostly covered upthread & in the linked thread(s), but as
> summary / elaboration:
>
> 1. Running the tests on some of these machines takes 30-45 minutes. A
> common use-case is firing off a test run to see how bright the
> dumpster fire is that day, noticing an early failure, and inspecting
> it manually.
>
> Then while the rest of the full run is underway I'd like to
> re-compile and e.g. add some printf debugging guarded by a getenv()
> to some isolated code I'm poking, it's nice if the full test run
> isn't invalidated by that.
>
> Keep in mind that it takes 30-45 minutes because it's *slooooooow*,
> so "just use another workdir" isn't a viable option. I'm also going
> to wait 10-20 minutes for another full recompile in that workdir
> (and now the concurrent test run takes more than an hour).
OK. If you are careful enough that makes sense.
> 2. We have bugs in the test suite that e.g. leave orphaned git-daemon
> background processes on these platforms.
>
> Yes that should be fixed, but fixing it is annoying when you can't
> even recompile and run other (even more broken) tests due to the bug
> you're trying to fix.
Yeah, that's a separate issue.
> 3. You're assuming that the only thing I might want to use the built
> git for is the tests.
Not really.
> 4. I think you/Junio/Jeff (although maybe less so in Jeff's case) are
> taking this axiom that thou shalt not recompile during tests as an
> absolute.
Just like in language I'm not a prescriptivist in workflows either. The
fact that I don't recompile during tests doesn't mean I would presume to
dictate to others what they should do.
You know more about your setup than me.
> I think you've also said something to the effect that the 3rd party tool
> should be the thing doing the in-place-rename if needed, fair
> enough.
>
> But claiming that it's both an external implementation detail (so it
> could do an in-place rename, or not), and also maintaining that we can't
> do in-place rename ourselves because doing so would enable bad thing XYZ
> to happen (i.e. this concurrent test thing), seems like a case of
> wanting to have your cake and eat it too.
I never claimed we can't do in-place rename ourselves, I only said that
I did not see the point. And to be clear the fact that I don't see it
doesn't mean it isn't here.
Now I see why you want this and I suppose for this particular case only
it does make sense to do the renaming. But it still seems like a wart to
me. If the build system supported out-of-tree builds there would be no
need for us to do this manually in the Makefile, correct?
But yeah, for now I suppose there's no better alternative.
--
Felipe Contreras
next prev parent reply other threads:[~2021-07-03 18:42 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
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 [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60e0af8f1636d_2f720865@natae.notmuch \
--to=felipe.contreras@gmail.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).