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

[Felipe Contreras <felipe.contreras@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