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?  Why
does /bin/rm matter in the first place?

Thanks for your quick feedback,
Ludo’.



Reply via email to