bug#16291: Use of /bin/rm
Hello! While upgrading the GNU system to Automake 1.14.1, I noticed that a few tests emit warnings like this: --8---cut here---start-8--- SKIP: t/spy-rm.tap 1 # SKIP /bin/rm not found PASS: t/spy-rm.tap 2 - rm -f SKIP: t/spy-rm.tap 3 # SKIP /bin/rm not found PASS: t/spy-rm.tap 4 - rm -rf SKIP: t/spy-rm.tap 5 # SKIP /bin/rm not found PASS: t/spy-rm.tap 6 - rm -fr --8---cut here---end---8--- There’s no /bin/rm in Guix build environments, hence the message (in fact, there’s no /bin at all.) However, in general, I think packages should not rely on hardcoded file names, and instead use AC_PATH_PROG or similar mechanisms to get the right file name. Would it be possible to change these tests to use ‘rm’ instead of /bin/rm? What do you think? Thanks, Ludo’.
bug#16291: Use of /bin/rm
tags 16291 notabug close 16291 stop On 12/29/2013 10:49 PM, Ludovic Courtès wrote: Hello! While upgrading the GNU system to Automake 1.14.1, I noticed that a few tests emit warnings like this: SKIPs are not warning, just informative messages explaining why some tests couldn't be run. --8---cut here---start-8--- SKIP: t/spy-rm.tap 1 # SKIP /bin/rm not found PASS: t/spy-rm.tap 2 - rm -f SKIP: t/spy-rm.tap 3 # SKIP /bin/rm not found PASS: t/spy-rm.tap 4 - rm -rf SKIP: t/spy-rm.tap 5 # SKIP /bin/rm not found PASS: t/spy-rm.tap 6 - rm -fr --8---cut here---end---8--- There’s no /bin/rm in Guix build environments, hence the message (in fact, there’s no /bin at all.) This is not a problem, since our test is smart enough to skip the checks that would require the non-existent /bin/rm program. However, in general, I think packages should not rely on hardcoded file names, and instead use AC_PATH_PROG or similar mechanisms to get the right file name. Not in this case. The test is a spy check that tries to determine whether either (1) the first 'rm' in PATH or (2) '/bin/rm' *if present* is deficient, in that it errors out when the -f option is specified and no non-option argument is passed. If /bin/rm does not exist, it can't be deficient, so the test correctly passes (I assume that happened in your setup, right? If not, that would be a bug, and you'd be justified to reopen this report). Would it be possible to change these tests to use ‘rm’ instead of /bin/rm? What do you think? That would be a bad idea, because we would miss warning from systems where /bin/rm is deficient but the user has installed a better rm (maybe from GNU coreutils) earlier in PATH. If all you are seeing are few SKIP messages and no failure, I don't think there is any problem to fix; everything is working as intended. Thanks, Stefano
bug#15949: Apparently out-of-date warning
On 12/27/2013 09:36 PM, Reuben Thomas wrote: On 26 December 2013 15:39, Stefano Lattarini stefano.lattar...@gmail.comwrote: But AM_PROG_AR truly does not define $RANLIB itself. Perhaps you are using libtool and calling AC_PROG_LIBTOOL or LT_INIT? Probably. So, how about changing the sentence from should to may need, I'd rather leave the wording as it is; the may need is IMHO confusing, and I don't want to commit ourselves to specify in which exact situation AC_PROG_RANLIB is required and when it can be dispensed with. Since specifying AC_PROG_RANLIB even when not strictly needed turns out to be basically a no-op and not to cause any problem, I'd leave sleeping dogs lie, and change nothing. or is there some reason why AM_PROG_AR cannot AC_REQUIRE ranlib so that the sentence can be deleted and no action is necessary? AM_PROG_AR is only required for people interested in having their package buildable with Microsoft tools; so we can't expect all packages to use it, and we'd still need to mandate the use AC_PROG_RANLIB for all packages not using AM_PROG_AR. At which point, it's easier to leave documentation and semantics as they are, IMHO. Regards, Stefano
bug#15949: Apparently out-of-date warning
On 29 December 2013 22:24, Stefano Lattarini stefano.lattar...@gmail.comwrote: AM_PROG_AR is only required for people interested in having their package buildable with Microsoft tools And we can't make AM_PROG_AR an automatic default? What would be the downside? (Sorry if I'm being a pain, but I find autotools a painful time sink, and I use it for many projects; anything that can be done to simplify it, however slightly, is a boon to both those of us who use it and those who refuse to on the grounds of excessive complexity and crankiness, with whom I all too often find myself sympathising!) -- http://rrt.sc3d.org
