Package: automake;
Reported by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Thu, 16 Feb 2012 20:44:01 UTC
Severity: wishlist
Done: Mike Frysinger <vapier <at> gentoo.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10828 in the body.
You can then email your comments to 10828 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Thu, 16 Feb 2012 20:44:01 GMT) Full text and rfc822 format available.Stefano Lattarini <stefano.lattarini <at> gmail.com>
:bug-automake <at> gnu.org
.
(Thu, 16 Feb 2012 20:44:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: Philip Rowlands <phr+coreutils <at> dimebar.com> Cc: "10819 <at> debbugs.gnu.org" <10819 <at> debbugs.gnu.org>, "bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>, Jim Meyering <jim <at> meyering.net>, Davide Brini <dave_br <at> gmx.com>, bug-automake <at> gnu.org, Eric Blake <eblake <at> redhat.com>, "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com> Subject: POSIX will say running "rm -f" with no argument is OK Date: Thu, 16 Feb 2012 21:41:03 +0100
Severity: wishlist [CC:ing bug-automake, so that we won't forget about this issue] Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10819#40> POSIX will say in a future version that running "rm -f" with no argument is OK; we might simplify several automake-generated "cleaning" rules accordingly, to get rid of the awful idiom: test -z "$(VAR)" || rm -f $(VAR) On 02/16/2012 08:15 PM, Philip Rowlands wrote: > On 16/02/2012 18:58, Eric Blake wrote: > >>> so that we could simplify a bunch of automake recipes); but a more extensive >>> probing is needed in this matter I guess. And if you are right (as I hope), >>> then this 'rm' feature could be documented in the Autoconf manual. >> >> Yep, I think that's appropriate, as it is unlikely that we will come up >> with any counterexamples any time soon. > > As the now-POSIX-infringing behaviour is simple to detect, couldn't automake detect > it early and die with a helpful message, or is that contrary to its philosophy? > Well, that might be an overkill, since it appears that all the non-museum implementations of 'rm' have the behaviour we want. But I agree that, in case we ever stumble upon a system violating this new expectation, adding proper configure-time probing and warning might be helpful (and might convince the users of such an inferior system to start using GNU coreutils). Regards, Stefano
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Thu, 03 Jan 2013 19:15:02 GMT) Full text and rfc822 format available.Message #8 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: 10828 <at> debbugs.gnu.org Subject: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Thu, 03 Jan 2013 20:14:36 +0100
Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10828> [This is posted also to the automake list to ensure a wider audience. Discussion should continue exclusively on the bug-automake list] OK, time to resurrect this thread. To summarize, POSIX will say in a future version that running "rm -f" with no argument is OK; and that usage seems today portable to all systems that are well on their way to obsolescence. So, in Automake 1.14, we might start to simplify several automake generated "cleaning" rules accordingly, to get rid of the awful idiom: test -z "$(VAR)" || rm -f $(VAR) In your opinion, can this be done without further fuss, or should we add a temporary "probe check" in AM_INIT_AUTOMAKE that verifies that the no-args "rm -f" usage is supported on the system configure is being run on? (As for a testsuite probe, that is already present; see tests 't/spy-rm.tap', already present in Automake 1.13). Comments welcome (and if your answer is "we should add a probe check", patches are even more welcome ;-) Regards, Stefano
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Wed, 09 Jan 2013 19:15:01 GMT) Full text and rfc822 format available.Message #11 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: automake-patches <at> gnu.org Cc: 10828 <at> debbugs.gnu.org Subject: [FYI] plans: automake 1.14 is to assume "rm -f" with no args is OK Date: Wed, 9 Jan 2013 20:14:29 +0100
See automake bug#10828. * PLANS/rm-f-without-args.txt: New. Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com> --- PLANS/rm-f-without-args.txt | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 PLANS/rm-f-without-args.txt diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt new file mode 100644 index 0000000..d5f96eb --- /dev/null +++ b/PLANS/rm-f-without-args.txt @@ -0,0 +1,40 @@ +Summary +------- + +POSIX will say in a future version that calling "rm -f" with no argument +is OK; and this sensible behaviour seem to be already very widespread in +"the wild" (and possibly lacking only on those systems that are well on +their way to obsolescence). + +Se we'd like to simplify several automake-generated "cleaning" rules +accordingly, to get rid of the awful idiom: + + test -z "$(VAR)" || rm -f $(VAR) + +See automake bug#10828. + +For Automake 1.13.2 (or 1.13.3) +------------------------------- + +Add a temporary "probe check" in AM_INIT_AUTOMAKE that verifies that +the no-args "rm -f" usage is supported on the system configure is +being run on; complain loudly (but not with a fatal error) if this is +not the case, and tell the user to report the situation to us. + +For Automake 1.14 +----------------- + +Make any failure in the configure-time probe check introduced by the +previous point fatal; and in case of failure, also suggest to the user +to install an older version of GNU coreutils to work around the +limitation of his system (this version should be old enough not to +be bootstrapped with Automake 1.14, otherwise the user will face a +bootstrapping catch-9). + +In all our recipes, start assuming "rm -f" with no argument is OK; +simplify and de-uglify the recipes accordingly. + +For Automake 1.15 +----------------- + +Remove the runtime probe altogether. -- 1.8.1.rc3.192.g2d0029e
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Wed, 16 Jan 2013 12:15:02 GMT) Full text and rfc822 format available.Message #14 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: automake-patches <at> gnu.org Cc: 10828 <at> debbugs.gnu.org Subject: [PATCH] init.m4: add probe to check "rm -f" without args work Date: Wed, 16 Jan 2013 13:13:18 +0100
On 01/09/2013 08:14 PM, Stefano Lattarini wrote: > See automake bug#10828. > > * PLANS/rm-f-without-args.txt: New. > > Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com> > --- > PLANS/rm-f-without-args.txt | 40 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > create mode 100644 PLANS/rm-f-without-args.txt > > diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt > new file mode 100644 > index 0000000..d5f96eb > --- /dev/null > +++ b/PLANS/rm-f-without-args.txt > @@ -0,0 +1,40 @@ > +Summary > +------- > + > +POSIX will say in a future version that calling "rm -f" with no argument > +is OK; and this sensible behaviour seem to be already very widespread in > +"the wild" (and possibly lacking only on those systems that are well on > +their way to obsolescence). > + > +Se we'd like to simplify several automake-generated "cleaning" rules > +accordingly, to get rid of the awful idiom: > + > + test -z "$(VAR)" || rm -f $(VAR) > + > +See automake bug#10828. > + > +For Automake 1.13.2 (or 1.13.3) > +------------------------------- > + > +Add a temporary "probe check" in AM_INIT_AUTOMAKE that verifies that > +the no-args "rm -f" usage is supported on the system configure is > +being run on; complain loudly (but not with a fatal error) if this is > +not the case, and tell the user to report the situation to us. > + Here is a patch implementing this first part of the plan. Note that, in order to improve the visibility of the loud warning, I have made it fatal by default; the user will still be able to instruct configure to continue anyway by setting the ACCEPT_INFERIOR_RM_PROGRAM environment variable to "yes" (that knob is mentioned in the fatal error message). I will push in a couple of days if there is no objection. Regards, Stefano ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- From f78b0f0b2741fcdd4e21151758a8a75ddaa8aa17 Mon Sep 17 00:00:00 2001 Message-Id: <f78b0f0b2741fcdd4e21151758a8a75ddaa8aa17.1358338329.git.stefano.lattarini <at> gmail.com> From: Stefano Lattarini <stefano.lattarini <at> gmail.com> Date: Sat, 12 Jan 2013 19:20:54 +0100 Subject: [PATCH] init.m4: add probe to check "rm -f" without args work See automake bug#10828. POSIX will say in a future version that running "rm -f" with no argument is OK: <http://austingroupbugs.net/view.php?id=542>). We want to be able to make that assumption in our Makefile recipes. So we introduce an aggressive probe to check that the usage we want is actually supported "in the wild" to an acceptable degree. * m4/init.m4 (AM_INIT_AUTOMAKE): Implement the probe. To make any issue more visible, cause the running configure to be aborted by default if the 'rm' program in use doesn't match our expectations; the user can still override this though, by setting the ACCEPT_INFERIOR_RM_PROGRAM environment variable to "yes". * t/spy-rm.tap: Update heading comments. * t/rm-f-probe.sh: New test. * t/list-of-tests.mk: Add it. * PLANS/rm-f-without-args.txt: Adjust. Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com> --- PLANS/rm-f-without-args.txt | 8 ++--- m4/init.m4 | 43 +++++++++++++++++++++++++- t/list-of-tests.mk | 1 + t/rm-f-probe.sh | 74 +++++++++++++++++++++++++++++++++++++++++++++ t/spy-rm.tap | 8 ++--- 5 files changed, 125 insertions(+), 9 deletions(-) create mode 100755 t/rm-f-probe.sh diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt index 5d39e22..5362f98 100644 --- a/PLANS/rm-f-without-args.txt +++ b/PLANS/rm-f-without-args.txt @@ -13,13 +13,13 @@ accordingly, to get rid of the awful idiom: See automake bug#10828. -For Automake 1.13.2 (or 1.13.3) -------------------------------- +For Automake 1.13.2 (DONE) +-------------------------- Add a temporary "probe check" in AM_INIT_AUTOMAKE that verifies that the no-args "rm -f" usage is supported on the system configure is -being run on; complain loudly (but not with a fatal error) if this is -not the case, and tell the user to report the situation to us. +being run on; complain loudly if this is not the case, and tell the +user to report the situation to us. For Automake 1.14 ----------------- diff --git a/m4/init.m4 b/m4/init.m4 index c5af65c..ce64a6c 100644 --- a/m4/init.m4 +++ b/m4/init.m4 @@ -117,7 +117,48 @@ dnl macro is hooked onto _AC_COMPILER_EXEEXT early, see below. AC_CONFIG_COMMANDS_PRE(dnl [m4_provide_if([_AM_COMPILER_EXEEXT], [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl -]) + +# POSIX will say in a future version that running "rm -f" with no argument +# is OK; and we want to be able to make that assumption in our Makefile +# recipes. So use an aggressive probe to check that the usage we want is +# actually supported "in the wild" to an acceptable degree. +# See automake bug#10828. +# To make any issue more visible, cause the running configure to be aborted +# by default if the 'rm' program in use doesn't match our expectations; the +# user can still override this though. +if rm -f && rm -fr && rm -rf; then : OK; else + cat >&2 <<'END' +Oops! + +Your 'rm' program seems unable to run without file operands specified +on the command line, even when the '-f' option is present. This is contrary +to the behaviour of most rm programs out there, and not conforming with +the upcoming POSIX standard: <http://austingroupbugs.net/view.php?id=542> + +Please tell bug-automake <at> gnu.org about your system, including the value +of your $PATH and any error possibly output before this message. This +can help us improve future automake versions. + +END + if test x"$ACCEPT_INFERIOR_RM_PROGRAM" = x"yes"; then + echo 'Configuration will proceed anyway, since you have set the' >&2 + echo 'ACCEPT_INFERIOR_RM_PROGRAM variable to "yes"' >&2 + echo >&2 + else + cat >&2 <<'END' +Aborting the configuration process, to ensure you take notice of the issue. + +You can download and install GNU coreutils to get an 'rm' implementation +that behaves properly: <http://www.gnu.org/software/coreutils/>. + +If you want to complete the configuration process using your problematic +'rm' anyway, export the environment variable ACCEPT_INFERIOR_RM_PROGRAM +to "yes", and re-run configure. + +END + AC_MSG_ERROR([Your 'rm' program is bad, sorry.]) + fi +fi]) dnl Hook into '_AC_COMPILER_EXEEXT' early to learn its expansion. Do not dnl add the conditional right here, as _AC_COMPILER_EXEEXT may be further diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk index 44f598e..0f5dbee 100644 --- a/t/list-of-tests.mk +++ b/t/list-of-tests.mk @@ -953,6 +953,7 @@ t/remake-macrodir.sh \ t/remake-timing-bug-pr8365.sh \ t/reqd2.sh \ t/repeated-options.sh \ +t/rm-f-probe.sh \ t/rulepat.sh \ t/self-check-cc-no-c-o.sh \ t/self-check-configure-help.sh \ diff --git a/t/rm-f-probe.sh b/t/rm-f-probe.sh new file mode 100755 index 0000000..1cb220a --- /dev/null +++ b/t/rm-f-probe.sh @@ -0,0 +1,74 @@ +#! /bin/sh +# Copyright (C) 2013 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# Verify our probe that checks that "rm -f" doesn't complain if called +# without file operands works as expected. See automake bug#10828. + +. test-init.sh + +echo AC_OUTPUT >> configure.ac +: > Makefile.am + +$ACLOCAL +$AUTOCONF +$AUTOMAKE + +mkdir bin +cat > bin/rm <<'END' +#!/bin/sh +set -e; set -u; +PATH=$original_PATH; export PATH +rm_opts= +while test $# -gt 0; do + case $1 in + -*) rm_opts="$rm_opts $1";; + *) break;; + esac + shift +done +if test $# -eq 0; then + echo "Oops, fake rm called without arguments" >&2 + exit 1 +else + exec rm $rm_opts "$@" +fi +END +chmod a+x bin/rm + +original_PATH=$PATH +PATH=$(pwd)/bin$PATH_SEPARATOR$PATH +export PATH original_PATH + +rm -f && exit 99 # Sanity check. + +./configure 2>stderr && { cat stderr >&2; exit 1; } +cat stderr >&2 + +grep "'rm' program.* unable to run without file operands" stderr +$FGREP "tell bug-automake <at> gnu.org about your system" stderr +$FGREP "install GNU coreutils" stderr +$EGREP "(^| |')ACCEPT_INFERIOR_RM_PROGRAM($| |')" stderr + +ACCEPT_INFERIOR_RM_PROGRAM=yes; export ACCEPT_INFERIOR_RM_PROGRAM + +./configure +$MAKE +$MAKE distcheck + +# For the sake of our exit trap. +PATH=$original_PATH; export PATH + +: diff --git a/t/spy-rm.tap b/t/spy-rm.tap index 29840ab..3b8dd2d 100755 --- a/t/spy-rm.tap +++ b/t/spy-rm.tap @@ -19,10 +19,10 @@ # to hold on all non-museum systems, and will soon be mandated # by POSIX as well) in future version of automake, to simplify # automake-provided cleanup rules. -# References: -# <http://lists.gnu.org/archive/html/bug-autoconf/2012-02/msg00002.html> -# <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10819> -# <http://austingroupbugs.net/view.php?id=542> +# See automake bug#10828. +# Other references: +# <http://lists.gnu.org/archive/html/bug-autoconf/2012-02/msg00002.html> +# <http://austingroupbugs.net/view.php?id=542> am_create_testdir=empty . test-init.sh -- 1.8.1.rc3.192.g2d0029e
Mike Frysinger <vapier <at> gentoo.org>
to control <at> debbugs.gnu.org
.
(Fri, 10 Dec 2021 05:45:02 GMT) Full text and rfc822 format available.Mike Frysinger <vapier <at> gentoo.org>
to control <at> debbugs.gnu.org
.
(Fri, 10 Dec 2021 05:45:02 GMT) Full text and rfc822 format available.Mike Frysinger <vapier <at> gentoo.org>
to control <at> debbugs.gnu.org
.
(Fri, 10 Dec 2021 05:45:02 GMT) Full text and rfc822 format available.bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Fri, 10 Dec 2021 05:48:02 GMT) Full text and rfc822 format available.Message #23 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Mike Frysinger <vapier <at> gentoo.org> To: Stefano Lattarini <stefano.lattarini <at> gmail.com> Cc: 10828 <at> debbugs.gnu.org Subject: Re: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Fri, 10 Dec 2021 00:47:46 -0500
[Message part 1 (text/plain, inline)]
On 03 Jan 2013 20:14, Stefano Lattarini wrote: > Reference: > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10828> > > [This is posted also to the automake list to ensure a wider audience. > Discussion should continue exclusively on the bug-automake list] > > OK, time to resurrect this thread. > > To summarize, POSIX will say in a future version that running "rm -f" > with no argument is OK; and that usage seems today portable to all > systems that are well on their way to obsolescence. > > So, in Automake 1.14, we might start to simplify several automake > generated "cleaning" rules accordingly, to get rid of the awful > idiom: > > test -z "$(VAR)" || rm -f $(VAR) > > In your opinion, can this be done without further fuss, or should we > add a temporary "probe check" in AM_INIT_AUTOMAKE that verifies that > the no-args "rm -f" usage is supported on the system configure is > being run on? (As for a testsuite probe, that is already present; > see tests 't/spy-rm.tap', already present in Automake 1.13). > > Comments welcome (and if your answer is "we should add a probe > check", patches are even more welcome ;-) what is the game plan here ? are we intending to keep the backwards compatible behavior ? or drop it entirely ? it seems like if we're going to go through the effort of adding a configure test to see if the `rm -f` behavior predates POSIX-2013, then doing an AC_SUBST to get the backwards compat behavior isn't that much overhead ? if it's dropped, i'm not sure how users are supposed to fix things. the error message says to install GNU coreutils, but if GNU coreutils uses automake and presents the same error ... in the years since this merged, we've gotten three reports: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19692 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22074 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23563 -mike
[signature.asc (application/pgp-signature, inline)]
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Fri, 10 Dec 2021 23:34:01 GMT) Full text and rfc822 format available.Message #26 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Peter Johansson <trojkan <at> gmail.com> To: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10828 <at> debbugs.gnu.org Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Sat, 11 Dec 2021 09:33:40 +1000
Hi Mike, On 10/12/21 15:47, Mike Frysinger wrote: > if it's dropped, i'm not sure how users are supposed to fix things. > the error message says to install GNU coreutils, but if GNU coreutils > uses automake and presents the same error ... FWIW, automake is not needed to build and install GNU coreutils from a released tarball. Cheers, Peter
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Sat, 11 Dec 2021 05:15:02 GMT) Full text and rfc822 format available.Message #29 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Mike Frysinger <vapier <at> gentoo.org> To: Peter Johansson <trojkan <at> gmail.com> Cc: 10828 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com> Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Sat, 11 Dec 2021 00:14:47 -0500
[Message part 1 (text/plain, inline)]
On 11 Dec 2021 09:33, Peter Johansson wrote: > On 10/12/21 15:47, Mike Frysinger wrote: > > if it's dropped, i'm not sure how users are supposed to fix things. > > the error message says to install GNU coreutils, but if GNU coreutils > > uses automake and presents the same error ... > > FWIW, automake is not needed to build and install GNU coreutils from a > released tarball. the issue isn't about running `automake`, it's about the generated Makefile using functionality that requires GNU coreutils. if an empty `rm -f` was invoked as part of the coreutils build process, then the user would be a bit stuck. admittedly it's a bit unlikely to show up outside of `make clean`, but coreutils is known to do some "extra" things (optional tools, generation of man pages, etc...), and i haven't fully looked at every place where automake will generate a `rm -f` pattern. do we have to self-regulate every time we try to use that in case it might break the bootstrap flow of coreutils ? i'm not saying we have to support this scenario. i'm just pointing out that it's not as cut & dry as we might hope it would be. it probably comes down to being a bit clearer on what autotools' goals are and what it considers reasonable prerequisites. the GNU config project has undergone a bit of lively debate in the last year about whether it can use POSIX shell features that have been standardized for over 30 years. it has decided that it cannot for some. automake clearly doesn't require GNU make. the manual says: > https://www.gnu.org/software/automake/manual/automake.html#Why-Autotools > * As we have seen, the GNU Build System has a lot of features ... > * Implementing these features portably is difficult and exhausting. Think of > writing portable shell scripts, and portable Makefiles, for systems you may > not have handy. See Portable Shell Programming in The Autoconf Manual, to > convince yourself. > * The GNU Autotools take all this burden off your back and provide: > * Tools to create a portable, complete, and self-contained GNU Build System, > from simple instructions. Self-contained meaning the resulting build system > does not require the GNU Autotools. so how is "portable" being defined ? clearly it's not "anything in the latest POSIX standard is fair game, and anything not supporting the latest POSIX standard is SOL". i think users of automake would be surprised by that when automake has a history of producing Makefile's packages that can be reliably built on older systems. if POSIX were a hard requirement, automake wouldn't carry support logic for Microsoft's lib archiver via `ar-lib`. so circling back, can we see a way of walking the `rm -f` line without the maintenance burden being too high ? e.g. a configure test that checks if `rm -f` exits non-zero, and some Makefile logic that is able to switch in the test in/out as needed ? we could set am__rm_f_suppress to - and just ignore all failures. it would allow packages to continue to build (if at the cost of being extra chatty) for such deficient setups. am__rm_f_suppress = @am__rm_f_suppress@ am__rm_f = $(am__rm_f_suppress)rm -f or do we document that we expect `rm -f` to work, and if it doesn't on your system, then hopefully you won't happen to run into the limitation when building the project (even if `make clean` might break). i.e. we turn the configure-time error into a warning, and then just hope for the best. nowhere do we use the `test ... || rm -f ...` pattern. based on the user reports thus far, i'm OK with the latter. -mike
[signature.asc (application/pgp-signature, inline)]
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Sat, 11 Dec 2021 09:06:02 GMT) Full text and rfc822 format available.Message #32 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Peter Johansson <trojkan <at> gmail.com> To: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10828 <at> debbugs.gnu.org Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Sat, 11 Dec 2021 19:05:42 +1000
Hi Mike, On 11/12/21 15:14, Mike Frysinger wrote: > On 11 Dec 2021 09:33, Peter Johansson wrote: >> On 10/12/21 15:47, Mike Frysinger wrote: >>> if it's dropped, i'm not sure how users are supposed to fix things. >>> the error message says to install GNU coreutils, but if GNU coreutils >>> uses automake and presents the same error ... >> FWIW, automake is not needed to build and install GNU coreutils from a >> released tarball. > the issue isn't about running `automake`, it's about the generated Makefile > using functionality that requires GNU coreutils. Correct. I was sloppy in my analysis. Apologies for the noise. > if an empty `rm -f` was > invoked as part of the coreutils build process, then the user would be a > bit stuck. > > admittedly it's a bit unlikely to show up outside of `make clean`, but > coreutils is known to do some "extra" things (optional tools, generation > of man pages, etc...), and i haven't fully looked at every place where > automake will generate a `rm -f` pattern. do we have to self-regulate > every time we try to use that in case it might break the bootstrap flow > of coreutils ? > > i'm not saying we have to support this scenario. i'm just pointing out > that it's not as cut & dry as we might hope it would be. > > it probably comes down to being a bit clearer on what autotools' goals are > and what it considers reasonable prerequisites. the GNU config project has > undergone a bit of lively debate in the last year about whether it can use > POSIX shell features that have been standardized for over 30 years. it has > decided that it cannot for some. > > automake clearly doesn't require GNU make. the manual says: >> https://www.gnu.org/software/automake/manual/automake.html#Why-Autotools >> * As we have seen, the GNU Build System has a lot of features ... >> * Implementing these features portably is difficult and exhausting. Think of >> writing portable shell scripts, and portable Makefiles, for systems you may >> not have handy. See Portable Shell Programming in The Autoconf Manual, to >> convince yourself. >> * The GNU Autotools take all this burden off your back and provide: >> * Tools to create a portable, complete, and self-contained GNU Build System, >> from simple instructions. Self-contained meaning the resulting build system >> does not require the GNU Autotools. > so how is "portable" being defined ? clearly it's not "anything in the latest > POSIX standard is fair game, and anything not supporting the latest POSIX > standard is SOL". i think users of automake would be surprised by that when > automake has a history of producing Makefile's packages that can be reliably > built on older systems. > > if POSIX were a hard requirement, automake wouldn't carry support logic for > Microsoft's lib archiver via `ar-lib`. > > so circling back, can we see a way of walking the `rm -f` line without the > maintenance burden being too high ? e.g. a configure test that checks if > `rm -f` exits non-zero, and some Makefile logic that is able to switch in > the test in/out as needed ? we could set am__rm_f_suppress to - and just > ignore all failures. it would allow packages to continue to build (if at > the cost of being extra chatty) for such deficient setups. > am__rm_f_suppress = @am__rm_f_suppress@ > am__rm_f = $(am__rm_f_suppress)rm -f > > or do we document that we expect `rm -f` to work, and if it doesn't on > your system, then hopefully you won't happen to run into the limitation > when building the project (even if `make clean` might break). i.e. we > turn the configure-time error into a warning, and then just hope for the > best. nowhere do we use the `test ... || rm -f ...` pattern. That seems reasonable. I'd say the minimal change would be to at least not call 'rm -f' directly but define a variable RM = rm -f so a user has some way around potential problems. Cheers, Peter
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Sat, 11 Dec 2021 21:53:02 GMT) Full text and rfc822 format available.Message #35 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Karl Berry <karl <at> freefriends.org> To: trojkan <at> gmail.com, 10828 <at> debbugs.gnu.org Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Sat, 11 Dec 2021 14:52:12 -0700
Hi Mike, Peter, > or do we document that we expect `rm -f` to work, I don't see a reason to break working code wrt rm -f merely for cosmetic purposes. test -z "$(VAR)" || rm -f $(VAR) does not actually seem "awful" to me. And I fail to see any significant gain by simplifying it. Whatever POSIX says, we can be sure that reality differs. Although systems that fail on "rm -f" are few and far between by now, they are not nonexistent. So why break them? My idea is to let the existing code stand (forever). In the alternative, I agree with Peter that at least providing an overridable variable would be desirable. --thanks, karl.
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Sat, 11 Dec 2021 22:05:01 GMT) Full text and rfc822 format available.Message #38 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Karl Berry <karl <at> freefriends.org> To: vapier <at> gentoo.org Cc: 10828 <at> debbugs.gnu.org, trojkan <at> gmail.com, stefano.lattarini <at> gmail.com Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Sat, 11 Dec 2021 15:04:22 -0700
it probably comes down to being a bit clearer on what autotools' goals are and what it considers reasonable prerequisites. I'd find it hard to define precisely. As a general rule, I wouldn't want to lose support for any system that is working now, until we can be really sure that it is no longer in use anywhere. For me, compatibility is the dominant criterion for any change. I made a foolish mistake recently wrt Python variables (a nice new feature, but I failed to ensure that existing behavior did not change), but hopefully it is back to normal in 1.16.5. about whether it can use POSIX shell features that have been standardized for over 30 years. it has decided that it cannot for some. And thank goodness that misguided $(...) change finally got reverted. clearly it's not "anything in the latest POSIX standard is fair game, and anything not supporting the latest POSIX standard is SOL". Clearly, and thank goodness for that too :). Thanks, Karl
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Sat, 11 Dec 2021 22:20:02 GMT) Full text and rfc822 format available.Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Moritz Klammler <moritz <at> klammler.eu> To: bug-automake <at> gnu.org Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Sat, 11 Dec 2021 23:19:08 +0100
[Message part 1 (text/plain, inline)]
Hi folks, hope you don't mind an outsider (occasional Autotools user) joining the discussion with some trivia. On 12/11/21 22:52, Karl Berry wrote: > Hi Mike, Peter, > > > or do we document that we expect `rm -f` to work, > > I don't see a reason to break working code wrt rm -f merely for cosmetic > purposes. > test -z "$(VAR)" || rm -f $(VAR) > does not actually seem "awful" to me. And I fail to see any significant > gain by simplifying it. I do have to say that I found it visually disturbing and the noise makes it harder for me to understand what an Automake recipe does. Especially when not looking at the code but the expended commands as printed during execution. > Whatever POSIX says, we can be sure that reality differs. > Although systems that fail on "rm -f" are few and far between by now, > they are not nonexistent. So why break them? > > My idea is to let the existing code stand (forever). > > In the alternative, I agree with Peter that at least providing an > overridable variable would be desirable. --thanks, karl. > An alternative trick which I have used in my code and found much less disturbing is to prepend an arbitrary, hopefully non-existent, file name so the list of arguments will never be empty even if the variable is. rm -f NOTFOUND $(VAR) Note that the suggested RM = rm -f $(RM) $(VAR) makes it very easy to inject this behavior; just set RM="rm -f NOTFOUND" and you're good to go. You don't have to be able to expand the argument list twice, which would be less trivial to inject. I'm not aware of any situation where this trick doesn't work.
[OpenPGP_signature (application/pgp-signature, attachment)]
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Mon, 13 Dec 2021 22:46:01 GMT) Full text and rfc822 format available.Message #44 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Karl Berry <karl <at> freefriends.org> To: automake <at> gnu.org, 10828 <at> debbugs.gnu.org Subject: Re: rm -f # no more args failure? Date: Mon, 13 Dec 2021 15:45:01 -0700
bf> I thought that systems deriving from OpenSolaris (e.g. Illumos, ... However, testing in an empty directory on a system without the upated ksh93 this looks ok to me: Bob, what you wrote before (approx. a year ago) is here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42529 Ending with: Behavior of ksh93 (which has a bug) appears to depend on the PATH setting so it will behave differently if /usr/xpg4/bin or /usr/xpg6/bin appear in the path. Maybe that is why you didn't see the behavior just now? In any case, if a broken "rm -f" still exists in a free system as late as last year, it seems premature to me to force this change now. I grant Moritz's point that the ubiquitious "test -z ... || rm ..." adds noise when trying to understand Automake recipes, but IMHO that is not enough reason to induce this incompatibility. mf> collected here as blockers: https://debbugs.gnu.org/10828 Thanks. No one active (i.e., me) was aware this was being done, so I didn't add Bob's report as a blocker when it came in. I grepped the bug archive for the error message ("Your.*rm.*program") and didn't see anything other than Bob's, but that could have missed some. there's only 3 reports filed from the last 10 years. Which I see are: May 2016 - MKS Platform component 9.X - bugs.gnu.org/23563 Dec 2015 - Unixware 7.1.4 - bugs.gnu.org/22074 Jan 2015 - Qnx 6.3.2 - bugs.gnu.org/19692 Looks like Unixware 7.1.4 may still be current, but since there are no later reports, I guess they're not really using Automake, or set the necessary envvar, or something. --karl
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Tue, 14 Dec 2021 02:05:02 GMT) Full text and rfc822 format available.Message #47 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Mike Frysinger <vapier <at> gentoo.org> To: Moritz Klammler <moritz <at> klammler.eu> Cc: 10828 <at> debbugs.gnu.org Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Mon, 13 Dec 2021 21:04:49 -0500
[Message part 1 (text/plain, inline)]
On 11 Dec 2021 23:19, Moritz Klammler wrote: > An alternative trick which I have used in my code and found much less > disturbing is to prepend an arbitrary, hopefully non-existent, file name > so the list of arguments will never be empty even if the variable is. > > rm -f NOTFOUND $(VAR) i think this is an interesting route. we could do: rm -f $(am__rm_f_notfound) ... and am__rm_f_notfound could be set based on the configure test. am__rm_f_notfound = WORKAROUND_RM_F_BUG that way most people won't see any noise. -mike
[signature.asc (application/pgp-signature, inline)]
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Tue, 14 Dec 2021 14:14:01 GMT) Full text and rfc822 format available.Message #50 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> To: Karl Berry <karl <at> freefriends.org> Cc: 10828 <at> debbugs.gnu.org, automake <at> gnu.org Subject: Re: rm -f # no more args failure? Date: Tue, 14 Dec 2021 08:13:29 -0600 (CST)
On Mon, 13 Dec 2021, Karl Berry wrote: > bf> I thought that systems deriving from OpenSolaris (e.g. Illumos, > ... > However, testing in an empty directory on a system without the > upated ksh93 this looks ok to me: > > Bob, what you wrote before (approx. a year ago) is here: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42529 > > Ending with: > Behavior of ksh93 (which has a bug) appears to depend on the PATH > setting so it will behave differently if /usr/xpg4/bin or > /usr/xpg6/bin appear in the path. > > Maybe that is why you didn't see the behavior just now? Yes, that must be the case. I updated my PATH to avoid the behavior. > In any case, if a broken "rm -f" still exists in a free system as late > as last year, it seems premature to me to force this change now. It does still exist in many deployed systems which have not yet been updated. In a year or two there will be fewer systems which lack the updated ksh93. > I grant Moritz's point that the ubiquitious "test -z ... || rm ..." > adds noise when trying to understand Automake recipes, but IMHO that is > not enough reason to induce this incompatibility. The cost is more a matter of lost execution time due to the fork/exec than annoying noise. Bob -- Bob Friesenhahn bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Wed, 15 Dec 2021 21:49:01 GMT) Full text and rfc822 format available.Message #53 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Karl Berry <karl <at> freefriends.org> To: vapier <at> gentoo.org Cc: 10828 <at> debbugs.gnu.org, moritz <at> klammler.eu Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Wed, 15 Dec 2021 14:48:55 -0700
> rm -f NOTFOUND $(VAR) i think this is an interesting route. I agree. we could do: rm -f $(am__rm_f_notfound) ... and am__rm_f_notfound could be set based on the configure test. Sounds plausible to me. The "only" problem is that there are dozens or hundreds of places in the code that do rm -f. They would all have to be inspected and changed (or not) ... -k
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Thu, 16 Dec 2021 04:04:02 GMT) Full text and rfc822 format available.Message #56 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Mike Frysinger <vapier <at> gentoo.org> To: Karl Berry <karl <at> freefriends.org> Cc: 10828 <at> debbugs.gnu.org, moritz <at> klammler.eu Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Wed, 15 Dec 2021 23:03:06 -0500
[Message part 1 (text/plain, inline)]
On 15 Dec 2021 14:48, Karl Berry wrote: > > rm -f NOTFOUND $(VAR) > i think this is an interesting route. > > I agree. > > we could do: > rm -f $(am__rm_f_notfound) ... > and am__rm_f_notfound could be set based on the configure test. > > Sounds plausible to me. The "only" problem is that there are dozens or > hundreds of places in the code that do rm -f. They would all have to be > inspected and changed (or not) ... -k the issue isn't `rm -f` exactly, it's `rm -f` with a variable that could be empty. so that narrows it down at least by half. if we focus on ones using the pattern `test -z ... || rm -f ...`, there's barely a dozen of those. i'm not sure we need to fully audit the tree and review every `rm`, just do a best effort and wait for feedback (i.e. bugs). we could add a helper var to further collapse the boiler plate. am__rm_f = rm -f $(am__rm_f_notfound) then the rule is a bit more palatable: $(am__rm_f) ... or if we want to claim namespace and make it something we want to export for users of automake akin to AC_PROG_LN_S, we could use RM_F. -mike
[signature.asc (application/pgp-signature, inline)]
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Fri, 17 Dec 2021 03:23:01 GMT) Full text and rfc822 format available.Message #59 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Karl Berry <karl <at> freefriends.org> To: vapier <at> gentoo.org, 10828 <at> debbugs.gnu.org Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK Date: Thu, 16 Dec 2021 20:22:49 -0700
Hi Mike, the issue isn't `rm -f` exactly, it's `rm -f` with a variable that could be empty. Sure. i'm not sure we need to fully audit the tree Seems desirable to make a best effort to look at every viable case. At any rate, it should be reproducible on OpenSolaris etc., as reported by Bob F earlier in this report. So I hope Bob could try any proposed patches and check for missing cases. we could add a helper var to further collapse the boiler plate. am__rm_f = rm -f $(am__rm_f_notfound) then the rule is a bit more palatable: $(am__rm_f) ... Personally I find making "rm -f" into a variable less readable than the original suggestion of: rm -f ... $(am__rm_f_notfound) The minor tweak that comes to my mind is that maybe the variable name would be better as $(am__rm_f_notfound_file): rm -f ... $(am__rm_f_notfound_file) or if we want to claim namespace and make it something we want to export for users of automake akin to AC_PROG_LN_S, we could use RM_F. Our hope/belief is that the proposed change would silently fix the problem. In which case I don't see a win to doing something in user namespace, having to document it, etc. (Incidentally, I'd never want to define a variable as simple as "RM_F" at this late date. Too much chance of collision ... AM_RM_F would be ok if we wanted to go this route, but, as I say, I don't see a reason at the moment.) --thanks, karl.
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Thu, 17 Feb 2022 09:07:02 GMT) Full text and rfc822 format available.Message #62 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Mike Frysinger <vapier <at> gentoo.org> To: 10828 <at> debbugs.gnu.org Subject: [PATCH] rm: handle -f w/no arguments gracefully Date: Thu, 17 Feb 2022 04:06:10 -0500
Fixes automake bug https://bugs.gnu.org/10828. Delete the configure check that would abort if `rm -f` does not work, and delete the plans to make this a hard requirement in the future. Instead, test to see if `rm -f` fails w/out arguments. If it does, define am__rm_f such that it always passes at least the "" argument when deleting files. If it doesn't fail, then we can omit the "". Then go through lib/am/ and update places where we use the pattern `test -z ... || rm -f ...` and replace with $(am__rm_f). * NEWS: Mention support for `rm -f` w/out arguments. * PLANS/rm-f-without-args.txt: Remove. * lib/am/check.am: Use new $(am__rm_f) helper. * lib/am/clean.am: Likewise. * lib/am/header-vars.am: Likewise. * lib/am/inst-vars.am: Likewise. * lib/am/libs.am: Likewise. * lib/am/ltlib.am: Likewise. * lib/am/progs.am: Likewise. * lib/am/texinfos.am: Likewise. * m4/init.m4: Delete `rm -f` checks and call _AM_PROG_RM_F. * m4/rmf.m4: Define new _AM_PROG_RM_F macro. * t/rm-f-probe.sh: Update test. --- NEWS | 4 ++++ PLANS/rm-f-without-args.txt | 40 ------------------------------------ lib/am/check.am | 8 ++++---- lib/am/clean.am | 4 ++-- lib/am/header-vars.am | 4 ++++ lib/am/inst-vars.am | 8 +++----- lib/am/libs.am | 2 +- lib/am/ltlib.am | 8 +++----- lib/am/progs.am | 5 ++--- lib/am/texinfos.am | 8 +++----- m4/init.m4 | 41 +------------------------------------ m4/rmf.m4 | 16 +++++++++++++++ t/rm-f-probe.sh | 26 +++++++++++------------ 13 files changed, 55 insertions(+), 119 deletions(-) delete mode 100644 PLANS/rm-f-without-args.txt create mode 100644 m4/rmf.m4 diff --git a/NEWS b/NEWS index 74ad6d612560..fbb3f758ce52 100644 --- a/NEWS +++ b/NEWS @@ -22,6 +22,10 @@ New in 1.17: - Generated file timestamp checks now handle filesystems with sub-second timestamp granularity dynamically. + - Systems with non-POSIX "rm -f" behavior are now supported, and intent to + drop support for them has been reversed. The ACCEPT_INFERIOR_RM_PROGRAM + setting no longer exists. + * Obsolescent features: - py-compile no longer supports Python 0.x or 1.x versions. Python 2.0, diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt deleted file mode 100644 index b940fc3e9000..000000000000 --- a/PLANS/rm-f-without-args.txt +++ /dev/null @@ -1,40 +0,0 @@ -Summary -------- - -POSIX will say in a future version that calling "rm -f" with no argument -is OK; and this sensible behaviour seem to be already very widespread in -"the wild" (and possibly lacking only on those systems that are well on -their way to obsolescence). - -Se we'd like to simplify several automake-generated "cleaning" rules -accordingly, to get rid of the awful idiom: - - test -z "$(VAR)" || rm -f $(VAR) - -See automake bug#10828. - -For Automake 1.14 (DONE) ------------------------- - -Add a temporary "probe check" in AM_INIT_AUTOMAKE that verifies that -the no-args "rm -f" usage is supported on the system configure is -being run on; complain loudly if this is not the case, and tell the -user to report the situation to us. - -For Automake 2.0 ----------------- - -Make any failure in the configure-time probe check introduced by the -previous point fatal; and in case of failure, also suggest to the user -to install an older version of GNU coreutils to work around the -limitation of his system (this version should be old enough not to -be bootstrapped with Automake 2.0, otherwise the user will face a -bootstrapping catch-22). - -In all our recipes, start assuming "rm -f" with no argument is OK; -simplify and de-uglify the recipes accordingly. - -For Automake 3.0 ----------------- - -Remove the runtime probe altogether. diff --git a/lib/am/check.am b/lib/am/check.am index a7201af76bc0..6648c011d721 100644 --- a/lib/am/check.am +++ b/lib/am/check.am @@ -405,8 +405,8 @@ RECHECK_LOGS = $(TEST_LOGS) ## ------------------------------------------ ## check-TESTS: %CHECK_DEPS% - @list='$(RECHECK_LOGS)'; test -z "$$list" || rm -f $$list - @list='$(RECHECK_LOGS:.log=.trs)'; test -z "$$list" || rm -f $$list + @list='$(RECHECK_LOGS)'; $(am__rm_f) $$list + @list='$(RECHECK_LOGS:.log=.trs)'; $(am__rm_f) $$list ## We always have to remove $(TEST_SUITE_LOG), to ensure its rule is run ## in any case even in lazy mode: otherwise, if no test needs rerunning, ## or a prior run plus reruns all happen within the same timestamp (can @@ -414,7 +414,7 @@ check-TESTS: %CHECK_DEPS% ## OTOH, this means that, in the rule for '$(TEST_SUITE_LOG)', we ## cannot use '$?' to compute the set of lazily rerun tests, lest ## we rely on .PHONY to work portably. - @test -z "$(TEST_SUITE_LOG)" || rm -f $(TEST_SUITE_LOG) + @$(am__rm_f) $(TEST_SUITE_LOG) @set +e; $(am__set_TESTS_bases); \ log_list=`for i in $$bases; do echo $$i.log; done`; \ trs_list=`for i in $$bases; do echo $$i.trs; done`; \ @@ -432,7 +432,7 @@ check-TESTS: %CHECK_DEPS% recheck: all %CHECK_DEPS% ## See comments above in the check-TESTS recipe for why remove ## $(TEST_SUITE_LOG) here. - @test -z "$(TEST_SUITE_LOG)" || rm -f $(TEST_SUITE_LOG) + @$(am__rm_f) $(TEST_SUITE_LOG) @set +e; $(am__set_TESTS_bases); \ ## We must only consider tests that had an unexpected outcome (FAIL ## or XPASS) in the earlier run. diff --git a/lib/am/clean.am b/lib/am/clean.am index 987e825ba77f..bf7eb81789fe 100644 --- a/lib/am/clean.am +++ b/lib/am/clean.am @@ -27,8 +27,8 @@ clean-generic: distclean-am: distclean-generic clean-am distclean-generic: - -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES) - -test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES) + -$(am__rm_f) $(CONFIG_CLEAN_FILES) + -test . = "$(srcdir)" || $(am__rm_f) $(CONFIG_CLEAN_VPATH_FILES) %DISTCLEAN_RMS% ## Makefiles and their dependencies cannot be cleaned by diff --git a/lib/am/header-vars.am b/lib/am/header-vars.am index cfc330e6506b..0256faed6d2b 100644 --- a/lib/am/header-vars.am +++ b/lib/am/header-vars.am @@ -140,6 +140,10 @@ am__make_dryrun = (target_option=n; $(am__make_running_with_option)) ## subdirectories, and decide whether to stop at the first error or not. am__make_keepgoing = (target_option=k; $(am__make_running_with_option)) +## Helper to handle `rm -f` failing with no arguments. +am__rm_f = rm -f $(am__rm_f_notfound) +am__rm_rf = rm -rf $(am__rm_f_notfound) + ## Some derived variables that have been found to be useful. pkgdatadir = $(datadir)/@PACKAGE@ pkgincludedir = $(includedir)/@PACKAGE@ diff --git a/lib/am/inst-vars.am b/lib/am/inst-vars.am index c17dd625d96f..fd35a7de1a16 100644 --- a/lib/am/inst-vars.am +++ b/lib/am/inst-vars.am @@ -59,15 +59,13 @@ am__base_list = \ ## to the directory where the files to be removed are, and to the list of ## such files. am__uninstall_files_from_dir = { \ -## Some rm implementations complain if 'rm -f' is used without arguments. - test -z "$$files" \ ## At least Solaris /bin/sh still lacks 'test -e', so we use the multiple ## tests below instead. We expect $dir to be either non-existent or a ## directory, so the failure we'll experience if it is a regular file ## is indeed desired and welcome (better to fail loudly thasn silently). - || { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \ - || { echo " ( cd '$$dir' && rm -f" $$files ")"; \ - $(am__cd) "$$dir" && rm -f $$files; }; \ + { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \ + || { echo " ( cd '$$dir' && rm -f" $$files ")"; \ + $(am__cd) "$$dir" && $(am__rm_f) $$files; }; \ } endif %?FIRST% diff --git a/lib/am/libs.am b/lib/am/libs.am index 52413521a088..a5e175e93160 100644 --- a/lib/am/libs.am +++ b/lib/am/libs.am @@ -103,4 +103,4 @@ endif %?INSTALL% .PHONY clean-am: clean-%DIR%LIBRARIES clean-%DIR%LIBRARIES: - -test -z "$(%DIR%_LIBRARIES)" || rm -f $(%DIR%_LIBRARIES) + -$(am__rm_f) $(%DIR%_LIBRARIES) diff --git a/lib/am/ltlib.am b/lib/am/ltlib.am index 6e3c065f4300..032f88169bda 100644 --- a/lib/am/ltlib.am +++ b/lib/am/ltlib.am @@ -109,7 +109,7 @@ endif %?INSTALL% .PHONY clean-am: clean-%DIR%LTLIBRARIES clean-%DIR%LTLIBRARIES: - -test -z "$(%DIR%_LTLIBRARIES)" || rm -f $(%DIR%_LTLIBRARIES) + -$(am__rm_f) $(%DIR%_LTLIBRARIES) ## 'so_locations' files are created by some linkers (IRIX, OSF) when ## building a shared object. Libtool places these files in the ## directory where the shared object is created. @@ -117,7 +117,5 @@ clean-%DIR%LTLIBRARIES: locs=`for p in $$list; do echo $$p; done | \ sed 's|^[^/]*$$|.|; s|/[^/]*$$||; s|$$|/so_locations|' | \ sort -u`; \ - test -z "$$locs" || { \ - echo rm -f $${locs}; \ - rm -f $${locs}; \ - } + echo rm -f $${locs}; \ + $(am__rm_f) $${locs} diff --git a/lib/am/progs.am b/lib/am/progs.am index 8b99ec5a8c54..db3fd9585761 100644 --- a/lib/am/progs.am +++ b/lib/am/progs.am @@ -93,9 +93,8 @@ uninstall-%DIR%PROGRAMS: -e 's/$$/$(EXEEXT)/' \ ?!BASE? -e 'x;s,[^/]*$$,,;G;s,\n,,' \ `; \ - test -n "$$list" || exit 0; \ echo " ( cd '$(DESTDIR)$(%NDIR%dir)' && rm -f" $$files ")"; \ - cd "$(DESTDIR)$(%NDIR%dir)" && rm -f $$files + cd "$(DESTDIR)$(%NDIR%dir)" && $(am__rm_f) $$files endif %?INSTALL% @@ -105,7 +104,7 @@ endif %?INSTALL% .PHONY clean-am: clean-%DIR%PROGRAMS clean-%DIR%PROGRAMS: -?!LIBTOOL? -test -z "$(%DIR%_PROGRAMS)" || rm -f $(%DIR%_PROGRAMS) +?!LIBTOOL? -$(am__rm_f) $(%DIR%_PROGRAMS) ## Under Cygwin, we build 'program$(EXEEXT)'. However, if this ## program uses a Libtool library, Libtool will move it in ## '_libs/program$(EXEEXT)' and create a 'program' wrapper (without diff --git a/lib/am/texinfos.am b/lib/am/texinfos.am index 4284b1ea76d5..896a2a007b76 100644 --- a/lib/am/texinfos.am +++ b/lib/am/texinfos.am @@ -386,14 +386,13 @@ mostlyclean-aminfo: ## Use '-rf', not just '-f', because the %*CLEAN% substitutions can also ## contain any directory created by "makeinfo --html", as well as the ## '*.t2d' and '*.t2p' directories used by texi2dvi and texi2pdf. - -rm -rf %MOSTLYCLEAN% + -$(am__rm_rf) %MOSTLYCLEAN% .PHONY clean-am: clean-aminfo clean-aminfo: ## Use '-rf', not just '-f'; see comments in 'mostlyclean-aminfo' ## above for details. -?TEXICLEAN? -test -z "%TEXICLEAN%" \ -?TEXICLEAN? || rm -rf %TEXICLEAN% +?TEXICLEAN? -$(am__rm_rf) %TEXICLEAN% .PHONY maintainer-clean-am: maintainer-clean-aminfo maintainer-clean-aminfo: @@ -405,7 +404,6 @@ maintainer-clean-aminfo: done ## Use '-rf', not just '-f'; see comments in 'mostlyclean-aminfo' ## above for details. -?MAINTCLEAN? -test -z "%MAINTCLEAN%" \ -?MAINTCLEAN? || rm -rf %MAINTCLEAN% +?MAINTCLEAN? -$(am__rm_rf) %MAINTCLEAN% endif %?LOCAL-TEXIS% diff --git a/m4/init.m4 b/m4/init.m4 index 6ef46d6692e7..e576b935d2a2 100644 --- a/m4/init.m4 +++ b/m4/init.m4 @@ -142,47 +142,8 @@ AC_CONFIG_COMMANDS_PRE(dnl [m4_provide_if([_AM_COMPILER_EXEEXT], [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl -# POSIX will say in a future version that running "rm -f" with no argument -# is OK; and we want to be able to make that assumption in our Makefile -# recipes. So use an aggressive probe to check that the usage we want is -# actually supported "in the wild" to an acceptable degree. -# See automake bug#10828. -# To make any issue more visible, cause the running configure to be aborted -# by default if the 'rm' program in use doesn't match our expectations; the -# user can still override this though. -if rm -f && rm -fr && rm -rf; then : OK; else - cat >&2 <<'END' -Oops! +AC_REQUIRE([_AM_PROG_RM_F]) -Your 'rm' program seems unable to run without file operands specified -on the command line, even when the '-f' option is present. This is contrary -to the behaviour of most rm programs out there, and not conforming with -the upcoming POSIX standard: <http://austingroupbugs.net/view.php?id=542> - -Please tell bug-automake <at> gnu.org about your system, including the value -of your $PATH and any error possibly output before this message. This -can help us improve future automake versions. - -END - if test x"$ACCEPT_INFERIOR_RM_PROGRAM" = x"yes"; then - echo 'Configuration will proceed anyway, since you have set the' >&2 - echo 'ACCEPT_INFERIOR_RM_PROGRAM variable to "yes"' >&2 - echo >&2 - else - cat >&2 <<'END' -Aborting the configuration process, to ensure you take notice of the issue. - -You can download and install GNU coreutils to get an 'rm' implementation -that behaves properly: <https://www.gnu.org/software/coreutils/>. - -If you want to complete the configuration process using your problematic -'rm' anyway, export the environment variable ACCEPT_INFERIOR_RM_PROGRAM -to "yes", and re-run configure. - -END - AC_MSG_ERROR([Your 'rm' program is bad, sorry.]) - fi -fi dnl The trailing newline in this macro's definition is deliberate, for dnl backward compatibility and to allow trailing 'dnl'-style comments dnl after the AM_INIT_AUTOMAKE invocation. See automake bug#16841. diff --git a/m4/rmf.m4 b/m4/rmf.m4 new file mode 100644 index 000000000000..2437a9f76a6d --- /dev/null +++ b/m4/rmf.m4 @@ -0,0 +1,16 @@ +## -*- Autoconf -*- +# Copyright (C) 2022 Free Software Foundation, Inc. +# +# This file is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +# _AM_PROG_RM_F +# --------------- +# Check whether 'rm -f' without any arguments works. +# https://bugs.gnu.org/10828 +AC_DEFUN([_AM_PROG_RM_F], +[am__rm_f_notfound= +AS_IF([(rm -f && rm -fr && rm -rf) 2>/dev/null], [], [am__rm_f_notfound='""']) +AC_SUBST(am__rm_f_notfound) +]) diff --git a/t/rm-f-probe.sh b/t/rm-f-probe.sh index 9cd3e8814b7d..8463f4fb63c5 100644 --- a/t/rm-f-probe.sh +++ b/t/rm-f-probe.sh @@ -14,8 +14,8 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see <https://www.gnu.org/licenses/>. -# Verify our probe that checks that "rm -f" doesn't complain if called -# without file operands works as expected. See automake bug#10828. +# Verify our probe that checks that "rm -f" behavior works. +# https://bugs.gnu.org/10828 . test-init.sh @@ -40,8 +40,8 @@ while test $# -gt 0; do shift done if test $# -eq 0; then - echo "Oops, fake rm called without arguments" >&2 - exit 1 + echo "Oops, fake rm called without arguments" >&2 #DELETE + exit 1 #CHANGE else exec rm $rm_opts "$@" fi @@ -54,19 +54,17 @@ export PATH original_PATH rm -f && exit 99 # Sanity check. -./configure 2>stderr && { cat stderr >&2; exit 1; } -cat stderr >&2 - -grep "'rm' program.* unable to run without file operands" stderr -$FGREP "tell bug-automake <at> gnu.org about your system" stderr -$FGREP "install GNU coreutils" stderr -$EGREP "(^| |')ACCEPT_INFERIOR_RM_PROGRAM($| |')" stderr +# Check that `rm -f` is detected as broken. +./configure +grep '^am__rm_f_notfound = ""$' Makefile -ACCEPT_INFERIOR_RM_PROGRAM=yes; export ACCEPT_INFERIOR_RM_PROGRAM +# Chagne the `rm -f` behavior to work. +sed -e '/#DELETE/d' -e '/#CHANGE/s:1:0:' bin/rm > bin/rm.tmp +cat bin/rm.tmp > bin/rm +# Check that `rm -f` is detected as working. ./configure -$MAKE -$MAKE distcheck +grep '^am__rm_f_notfound = *$' Makefile # For the sake of our exit trap. PATH=$original_PATH; export PATH -- 2.34.1
bug-automake <at> gnu.org
:bug#10828
; Package automake
.
(Wed, 23 Feb 2022 21:49:01 GMT) Full text and rfc822 format available.Message #65 received at 10828 <at> debbugs.gnu.org (full text, mbox):
From: Karl Berry <karl <at> freefriends.org> To: vapier <at> gentoo.org Cc: 10828 <at> debbugs.gnu.org Subject: Re: bug#10828: [PATCH] rm: handle -f w/no arguments gracefully Date: Wed, 23 Feb 2022 14:48:00 -0700
Subject: bug#10828: [PATCH] rm: handle -f w/no arguments gracefully Patch looks good to me (just reading through it). Thanks for doing all that work. -k
Mike Frysinger <vapier <at> gentoo.org>
to control <at> debbugs.gnu.org
.
(Thu, 24 Feb 2022 03:10:03 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Thu, 24 Mar 2022 11:24:07 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.