Re: [PATCH] tests: add a syntax check for last week's global change

[Jim Meyering]

Eric Blake wrote:
> [adding bug-gnulib]
>
> On 11/27/2011 01:17 PM, Jim Meyering wrote:
>> Someone should have dinged me ;-)
>> Last week I made a global change but forgot to add a matching
>> syntax-check rule.
>>
>>>From 5b3e538b7fc193f8e54b16aeb99b48f28744c1db Mon Sep 17 00:00:00 2001
>> From: Jim Meyering <address@hidden>
>> Date: Sun, 27 Nov 2011 15:36:06 +0100
>> Subject: [PATCH] tests: add a syntax check for last week's global change
>
> "last week's global change" at commit a2c811db was specific to
> coreutils, but it stemmed from fallout in changes to gnulib's init.sh, I
> think this syntax-check belongs in gnulib.  At least libvirt would also
> benefit from this syntax check, as it had several cases of passing
> 'compare' the arguments in the wrong order.
>>
>> Last week I made a global change, commit a2c811db, `tests: use
>> "compare exp out", not "compare out exp"', but forgot to add a
>> corresponding syntax check rule.  Without that, it is far too
>> easy to add a new test or to merge in an old one that would
>> be non-conforming.  Obviously this is only a heuristic, since
>> it relies on the expected-output file to have a name that starts
>> with "exp".
>> * cfg.mk (sc_prohibit_reversed_compare_failure): Prohibit use of
>> compare with reversed arguments.
>> ---
>>  cfg.mk |    6 ++++++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>
> That is, any objections to moving this out of coreutil's cfg.mk and into
> gnulib's maint.mk?

I was reluctant to do that because "compare" is a pretty common word,
and I didn't try to limit the rule to a particular (tests/) directory.
If it works in libvirt with no false positives, that is a pretty good
indication that we don't need to worry about them just yet.

If it comes to that, we could limit the rule to packages that have
gnulib's init.sh.

So, yes, this is fine with me.
Welcome actually, so we'll benefit also via grep, diffutils, parted,
etc., without having to add to their local cfg.mk files.

Thanks.

You're welcome to remove it from coreutils' cfg.mk, too.