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
Description: PGP signature