On Mon, Mar 29 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> It'll also guard against any weird issues with e.g. a command that >> wants to read GIT-PERL-DEFINES to generate one of the %.perl scripts >> racing with either a concurrent instance of "make" that has partially >> updated the file, or test-lib.sh dying with some particularly weird >> error because GIT-BUILD-OPTIONS was partway through being updated when >> it ran. > > If something like that happens, doesn't that indicate a bug in the > dependency graph in the Makefile or the implementation of "make"? > The generated file is depended on for the consumer to be able to use > a non-stale version---so the consumer should not start before the > generator finishes. If everything we were building in the Makefile would be invoked via other Makefile rules, yes. But if I run say (cd t && ./t0000-basic.sh) I'm having test-lib.sh pick up one of those (possibly partial) files, this guarantees they'll all be atomically updated. > You may be able to hide the breakage coming from "partially written > file is easily recognizable and the consumer would barf". But I am > afraid that you are introducing a problem harder to diagnose, i.e. > "the consumer reads from a complete file so there is no syntax error > or other things that easily tells you there is a breakage, but what > is used is stale and not up to date". > > The same comment applies to this step. I do not think it would > break (other than adding intermediate crufts) the result if you > generate into temporary and rename to final, but it is not clear > to me what the point is in doing so. I just think it makes sense to do this for consistency. So on "master" we've got 65 hits for $@+ in the Makefile, at the end of this saga we've got 100. I think being consistent across the board makes things easier to read, and in combination with the later ".DELETE_ON_ERROR" we can also drop other copy/paste cruft.
