Re: maint.mk syntax check problems

[Jim Meyering]

Stefano Lattarini wrote:
...
>> Converting to a stand-alone script is a fine and seductive idea.
>
> About an yaer ago I had proposed a similar move for automake's own
> maintainer checks; see this RFC patch:
> <http://lists.gnu.org/archive/html/automake-patches/2010-07/msg00081.html>

At first glance, I do like it, and I'm sure that a perl-based
implementation would be far more efficient, and probably faster
even if the perl implementation doesn't run its tests in parallel.

Maybe I just have to view the new test framework as something
to be run alongside (or independent of) the existing one.
Then, eventually we can phase out the Makefile-based rules.
With a good Perl-based harness, I'll certainly be glad to phase
out (of projects I maintain) the make-based tests.

> The idea has been rejected though, as Ralf was afraid this move could be a
> creeping NIH-ism and impose an extra maintainance burden; he hoped instead
> to start using the gnulib infrastructure for maintainer-checks.
> If there is interest, I can try to resurrect that patch, this time with
> the aim of having it finally integrated into gnulib. Of course, some
> preliminary discussions about design goals and usage requirements are in
> order in this case.

I am interested.

>> However, the details make the task look like it would be disruptive
>> or counterproductive.
>>
>> Some of the tests may be easy to extract and convert, but many use
>> things like _sc_search_regexp and VC_LIST_EXCEPT, which are also used in
>> per-project tests (i.e., in cfg.mk), so even if we converted all of the
>> tests in maint.mk, we'd have to leave those definitions in maint.mk
>> and duplicate their functionality in this new script.
>>
>> Also, every project that currently records exemptions via
>> .x-sc_* files or exclude_file_name_regexp--sc_* variables...
>> continuing to support those mechanisms while also supporting
>> "source some-new-file" configuration would be a challenge.
>> And I do not relish the idea of being forced to convert
>> every project to use the new framework.
>>
>> The same applies to all of our customizations in cfg.mk
>> that change how particular tests work.
>>
>
> OK, so probably there isn't much interest ... oh well. I'm sending
> the above pointer to my patch anyway, merely as an FYI; this shouldn't
> hurt I guess.

For a significant enough improvement, I'm game.
Perl is well suited to this task.
I'm sure some will object to Perl's syntax, but not I.

IMHO, these tests are things that you write once and then
use many many times.  Robustness, flexibility and efficiency
are far more important that making their sources readable to
a larger community.  Besides, once you learn a few rules,
it's not hard to understand how they work.

I'm glad to see that you've already started on this.