bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK


From: Mike Frysinger
Subject: bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK
Date: Sat, 11 Dec 2021 00:14:47 -0500

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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]