From: "Ævar Arnfjörð Bjarmason" <email@example.com> To: Junio C Hamano <firstname.lastname@example.org> Cc: email@example.com, Jeff King <firstname.lastname@example.org>, Johannes Schindelin <email@example.com>, Jonathan Nieder <firstname.lastname@example.org> Subject: Re: [PATCH v2 2/5] Makefile: rename scripts in-place, don't clobber Date: Tue, 30 Mar 2021 01:28:01 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Mon, Mar 29 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <email@example.com> 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.
next prev parent reply other threads:[~2021-03-29 23:29 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-07 13:20 [PATCH] Makefile: generate 'git' as 'cc [...] -o git+ && mv git+ git' Ævar Arnfjörð Bjarmason 2021-03-07 20:41 ` Junio C Hamano 2021-03-08 12:38 ` Ævar Arnfjörð Bjarmason 2021-03-08 17:21 ` Junio C Hamano 2021-03-08 18:26 ` Jeff King 2021-03-29 16:20 ` [PATCH v2 0/5] Makefile: don't die on AIX with open ./git Ævar Arnfjörð Bjarmason 2021-03-29 16:20 ` [PATCH v2 1/5] Makefile: rename objects in-place, don't clobber Ævar Arnfjörð Bjarmason 2021-03-29 18:21 ` Junio C Hamano 2021-03-29 18:26 ` Junio C Hamano 2021-03-29 23:24 ` Ævar Arnfjörð Bjarmason 2021-03-30 0:21 ` Junio C Hamano 2021-03-31 14:17 ` Ævar Arnfjörð Bjarmason 2021-03-31 18:50 ` Junio C Hamano 2021-03-29 16:20 ` [PATCH v2 2/5] Makefile: rename scripts " Ævar Arnfjörð Bjarmason 2021-03-29 18:40 ` Junio C Hamano 2021-03-29 23:28 ` Ævar Arnfjörð Bjarmason [this message] 2021-03-29 16:20 ` [PATCH v2 3/5] Makefile: don't needlessly "rm $@ $@+" before "mv $@+ $@" Ævar Arnfjörð Bjarmason 2021-03-29 18:46 ` Junio C Hamano 2021-03-29 16:20 ` [PATCH v2 4/5] Makefile: add the ".DELETE_ON_ERROR" flag Ævar Arnfjörð Bjarmason 2021-03-29 18:51 ` Junio C Hamano 2021-03-29 23:31 ` Ævar Arnfjörð Bjarmason 2021-03-29 23:58 ` Junio C Hamano 2021-03-30 15:11 ` Jeff King 2021-03-30 18:36 ` Junio C Hamano 2021-03-31 6:58 ` Jeff King 2021-03-31 18:36 ` Junio C Hamano 2021-03-31 22:29 ` Johannes Schindelin 2021-03-29 16:20 ` [PATCH v2 5/5] Makefile: don't "rm configure" before generating it Ævar Arnfjörð Bjarmason 2021-03-29 16:31 ` [PATCH 0/6] Makefile: make non-symlink & non-hardlink install sane Ævar Arnfjörð Bjarmason 2021-03-29 16:31 ` [PATCH 1/6] Makefile: symlink the same way under "symlinks" and "no hardlinks" Ævar Arnfjörð Bjarmason 2021-03-29 22:17 ` Junio C Hamano 2021-03-29 16:31 ` [PATCH 2/6] Makefile: begin refactoring out "ln || ln -s || cp" pattern Ævar Arnfjörð Bjarmason 2021-03-29 22:20 ` Junio C Hamano 2021-03-29 16:31 ` [PATCH 3/6] Makefile: refactor " Ævar Arnfjörð Bjarmason 2021-03-29 22:24 ` Junio C Hamano 2021-03-30 15:20 ` Jeff King 2021-03-30 18:36 ` Junio C Hamano 2021-03-29 16:31 ` [PATCH 4/6] Makefile: make INSTALL_SYMLINKS affect the build directory Ævar Arnfjörð Bjarmason 2021-03-29 22:31 ` Junio C Hamano 2021-03-31 14:04 ` Ævar Arnfjörð Bjarmason 2021-03-29 16:31 ` [PATCH 5/6] Makefile: use "ln -f" instead of "rm && ln" Ævar Arnfjörð Bjarmason 2021-03-29 22:46 ` Junio C Hamano 2021-03-29 16:31 ` [PATCH 6/6] Makefile: add a INSTALL_FALLBACK_LN_CP mode Ævar Arnfjörð Bjarmason 2021-03-29 22:53 ` Junio C Hamano 2021-03-31 14:03 ` Ævar Arnfjörð Bjarmason 2021-03-31 18:45 ` Junio C Hamano 2021-03-31 19:01 ` Ævar Arnfjörð Bjarmason 2021-03-29 23:08 ` [PATCH 0/6] Makefile: make non-symlink & non-hardlink install sane Junio C Hamano
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2 2/5] Makefile: rename scripts in-place, don'\''t clobber' \ /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
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 NNTP newsgroup(s).