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 1/5] Makefile: rename objects in-place, don't clobber Date: Wed, 31 Mar 2021 16:17:10 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Tue, Mar 30 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <email@example.com> writes: > >>> Really, does anybody else use "$(CC) -o $@" in such a way in their >>> Makefile? Having to do this smells simply crazy (I am not saying >>> you are crazy---the platform that forces you to write such a thing >>> is crazy). >> >> Yes, if you do say a Google search for "Cannot open or remove a file >> containing a running program" you'll find that there's 15k results of >> people basically (re)discovering this problem in porting their software >> to AIX, and the solutions being some variant of "yes AIX sucks, just use >> this 'cmd >x+ && mv x+ x' trick". > > What I meant was if there are well known upstream projects whose > Makefile actually use > > $(CC) -o $@+ ... > mv $@+ $@ > > I wouldn't be surprised if AIX community maintained collections of > patches to many projects to turn > > $(CC) -o $@ ... > > in the Makefiles taken from upstream projects into > > $(CC) -o $@+ ... > mv $@+ $@ > > to work AIX around. As an upstream, however, I am not interested in > forcing that pattern on users of other platforms. Who's going to notice or care? We have some mixture of clobbering, "mv $@+ $@" etc. now in our Makefile for various rules and I think unless you're debugging those specific rules you won't notice. The case of the $@+ being left behind is quite obscure, and with *+ in our .gitignore won't be noticed (e.g. by a "git add ." or something). > In any case, I do not care too much about the "I am building a new > binary while running, without installing, the one I built" use case > and do not agree with the idea of making the Makefile ugly only to > support such a use case. That is where my comments are coming from > on this topic. FWIW, AIX developers who do not do the "build, run > without installing, and rebuild while the old one is still running" > will not need the "$(CC) -o $@+ && mv $@+ $@" either, right? I daresay that uses cases of: * The tests break, you login to the CI to run gdb, fix a small bug, compile (doesn't work), but being forced to close that gdb session would be annoying (e.g. maybe I'm just looking at a data in a struct I didn't change). * Ditto, but maybe debugging two things at the same time, having an open "cat-file --batch" session etc. Aren't something obscure to someone wanting to work on a codebase. I'm submitting these because this is an active impediment to me submitting portability patches on AIX, of which I already have some: git log --grep=AIX --author=Ævar origin/master Anything that makes that less painful is a win, and the tiny amount of Makefile complexity seems worth it to me.
next prev parent reply other threads:[~2021-03-31 14:17 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 [this message] 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 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 1/5] Makefile: rename objects 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).