On 12/30/2013 04:44 PM, Ludovic Courtès wrote: > Stefano Lattarini <stefano.lattar...@gmail.com> skribis: > >> On 12/29/2013 10:49 PM, Ludovic Courtès wrote: > > [...] > >>> 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? > > Yes. > >>> 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. > > Yes, of course. > > However, I’m still wondering: do Automake-generated makefiles and > Autoconf macros explicitly attempt to use /bin/rm in normal use? > Re Automake: not that I'm aware of. Have you any proof this is not the case?
Re Autoconf: that should be asked on the autoconf list. > Why does /bin/rm matter in the first place? > > Thanks for your quick feedback, > Ludo’. > Regards, Stefano