Hi folks,hope you don't mind an outsider (occasional Autotools user) joining the discussion with some trivia.
On 12/11/21 22:52, Karl Berry wrote:
Hi Mike, Peter,
> or do we document that we expect `rm -f` to work,
I don't see a reason to break working code wrt rm -f merely for cosmetic
purposes.
test -z "$(VAR)" || rm -f $(VAR)
does not actually seem "awful" to me. And I fail to see any significant
gain by simplifying it.
I do have to say that I found it visually disturbing and the noise makes it harder for me to understand what an Automake recipe does. Especially when not looking at the code but the expended commands as printed during execution.
Whatever POSIX says, we can be sure that reality differs. Although systems that fail on "rm -f" are few and far between by now, they are not nonexistent. So why break them? My idea is to let the existing code stand (forever). In the alternative, I agree with Peter that at least providing an overridable variable would be desirable. --thanks, karl.
An alternative trick which I have used in my code and found much less disturbing is to prepend an arbitrary, hopefully non-existent, file name so the list of arguments will never be empty even if the variable is.
rm -f NOTFOUND $(VAR) Note that the suggested RM = rm -f $(RM) $(VAR)makes it very easy to inject this behavior; just set RM="rm -f NOTFOUND" and you're good to go. You don't have to be able to expand the argument list twice, which would be less trivial to inject.
I'm not aware of any situation where this trick doesn't work.
OpenPGP_signature
Description: OpenPGP digital signature
