On Thu, Jun 24, 2021 at 03:53:51PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> ..and "this behavior is really annoying on one platform we target, and > >> the fix is rather trivial". > > > > Yeah, that's a fine reason, too. I'm not entirely clear on what the > > problem is, though, or why this is the best solution (I expect you > > probably explained it in an earlier thread/series, but if so it went in > > one ear and out the other on my end). > > On *nix systems you can open a file, and unlink() it in another process, > on Windows this is an error. > > AIX has its own variant of this annoying behavior, you can't clobber (or > open for writing) binaries that are currently being run, you can unlink > and rename them though. Ah, right. Thanks for refreshing me. TBH, I don't find this that serious a problem. Your compile will fail. But is rebuilding in the middle of a test run something it's important to support seamlessly? It seems like a bad practice in the first place. It would likewise be a problem if you were running regular git commands straight out of your build directory. And we do support that, but IMHO it is not that important a use case. So again, I'm not all that opposed to atomic rename-into-place generation. But the use case doesn't seem important to me. > So without that "mv $@ $@+" trick you can't recompile if you have a > concurrent test (that you don't care about failing) running, and we have > bugs in our tests where e.g. "git-daemon" gets lost and won't get killed > on that platform, so you can't recompile and test without tracking it > down and killing it. The "git-daemon" thing sounds like a separate bug that is maybe exacerbating things. But we'd want to fix it anyway, since even without blocking compilation, it will cause a re-run of the tests to use the wrong version (and either fail, or hit the auto-skip behavior). I've run into this with apache hanging around after tests were killed (we do try to clean up, but depending how the script is killed, that may or may not succeed). -Peff
