automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

maintainer checks (was: Re: [PATCH] {maint} Improve and extend tests on


From: Stefano Lattarini
Subject: maintainer checks (was: Re: [PATCH] {maint} Improve and extend tests on de-ansification support.)
Date: Sat, 20 Nov 2010 16:33:18 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Saturday 20 November 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Tue, Nov 16, 2010 at 12:15:12AM CET:
> > On Monday 15 November 2010, Ralf Wildenhues wrote:
> > > 
> > > Well then we should adjust maintainer-check to not complain.  Either
> > > way, maintainer-check results should not deteriorate.
> 
> > I'm not keen on meddling with the current maintainer-check rules, which
> > are already quite hackish and not very easy to extend IMHO.
> 
> ;-)
> 
> > So I'd like
> > to seize this opportunity to push again my patch on a re-implementation
> > of maintainer-check (in perl), which offers easy whitelisting of false
> > positives, and more flexibility in pre-processing the input lines (which
> > can be useful in case of more complex checks):
> >  <http://lists.gnu.org/archive/html/automake-patches/2010-07/msg00084.html>
> 
> Gnulib has a few more facilities in this area, and several GNU projects
> use them already.
>
Do these facilities allow whitelisting at least at the "file:line" level?
Do they allow whitelisting through (possibly file-specific) regexps?  If
yes, then I agree that we should use them instead of diverging more and
add more code duplication.  If not, they are not flexible enough IMHO.

> It would be good if we worked toward common facilities here, rather than 
> diverging more from it.

> Besides, I kinda dislike using perl where sed would suffice.
>
But it does not suffice, unless you can think of an easy way to do
the whitelisting described above with grep+sed (personally, I can't).

> Yes, I'm probably being selfish and stubborn on this one ...
>
;-)

> Another nit at cited patch of yours is that makefile rules run in
> parallel, the perl script tests don't.
>
ATM, the time required to run all the maintchecks is low enough that
this is not a problem.  And IMHO we can always optimize later if speed
becomes a problem.

> This helps speed, but also allows me to choose between stopping
> on first error or not (make -k).
>
My perl script never stops at the first error: I saw no reason to
allow such a behaviour.  But I think we could easily enhance the
script to make that configurable, if it's desiderable.  It's still
just an "RFC" after all.

BTW, a much more serious limitation of my script is that it currently
doesn't work in VPATH builds -- which is unacceptable.  Suggestions
about how to fix that without complicating the script too much are
very welcome.

Regards,
   Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]