Re: new syntax-check rule for @acronym?

[Jim Meyering]

Simon Josefsson wrote:
> Jim Meyering <address@hidden> writes:
>> Eric Blake wrote:
>>> On 03/24/2010 01:46 AM, Simon Josefsson wrote:
>>>>>     syntax-check test for this seems useful, to foster harmonization 
>>>>> across
>>>>>     GNU packages.  How about the patch below?
>>>>>
>>>>> I have no objection, certainly.
>>>>
>>>> I pushed the patch below.
>>>>
>>>> +# Don't use Texinfo @acronym{} as it is not a good idea.
>>>> +sc_texinfo_acronym:
>>>> +  @grep -nE '@acronym{'                                           \
>>>> +      $$($(VC_LIST_EXCEPT) | grep -E '\.texi$$') &&               \
>>>> +    { echo '$(ME): found use of Texinfo @acronym{}' 1>&2;         \
>>>> +      exit 1; } || :
>>>
>>> This hangs for non-GNU projects, like libvirt, that have no .texi
>>> documentation.  We really need to make progress on the patch to refactor
>>> maint.mk rules per Jose's ideas:
>>> http://lists.gnu.org/archive/html/bug-gnulib/2010-02/msg00242.html
>>> which would conveniently fix this rule in the process.
>>
>> IMHO, the address@hidden rule belongs in an optionally-enabled class
>> of tests.  Otherwise, I'll end up disabling it in nearly every package
>> I maintain.  I agree that it's not easy to maintain (esp if you don't
>> automate checks for it), but I do find that using @acronym does add a
>> tiny bit of useful mark-up, and it seems counter-productive to remove
>> it globally.
>
> There is a bunch of similar tests (e.g., what is the global
> justification for sc_prohibit_strcmp or sc_GPL_version?  those seems
> project specific to me) so an optional class may make sense -- however
> it IS very easy to disable tests on a per-project basis, I do so in
> several projects.  Libidn cfg.mk:
>
> local-checks-to-skip = sc_prohibit_strcmp sc_prohibit_have_config_h   \
>       sc_require_config_h sc_require_config_h_first                   \
>       sc_prohibit_HAVE_MBRTOWC sc_program_name sc_trailing_blank      \
>       sc_useless_cpp_parens sc_GPL_version sc_immutable_NEWS          \
>       sc_two_space_separator_in_usage sc_m4_quote_check sc_po_check   \
>       sc_copyright_check

Some of those are definitely not useful to many projects,
but when they're useful to at least 5 or 6 projects, it's hard
to argue for their outright removal.

> GNU SASL cfg.mk:
>
> local-checks-to-skip = sc_prohibit_strcmp sc_error_message_uppercase  \
>       sc_prohibit_have_config_h sc_require_config_h                   \
>       sc_require_config_h_first sc_unmarked_diagnostics               \
>       sc_GPL_version sc_immutable_NEWS sc_copyright_check
>
> I fear that having optional tests will lead to nobody using them.  By

It's not too hard to check out the sources for all gnulib-using projects
(at least the ones listed in users.txt) and run "grep test_name */cfg.mk"

> enabling all tests by default, and forcing package maintainers to
> actively do something to disable them, we at least make sure there is
> some manual review of the situation on a per-project basis.

It's a fine line.
There are two issues:
  - making initial integration easier (having to add fewer exemptions)
  - making it easier for projects to track the latest gnulib
Perhaps I personally feel the inconvenience more than most when a new
rule is added and I decide to exclude it: I may have to add it to the
list in 5 or 6 projects.

Here's how I envisioned configuring syntax-check:
  - select all tests that are available and exempt a few
  - select only the "uncontroversial" tests, maybe exempting one or two, and
      add a few of the more aggressive ones

But I do see your point and am in no hurry to add some new category,
so I'll probably just exempt the new test where required.

> Of course, there is also the more specific question of whether @acronym
> deserves to die, but the way I read Karl's suggestion to the automake
> project, that is what I inferred.