Re: [PATCH] {maint} maintcheck: look for problematic names of testcases

[Stefano Lattarini]

On Tuesday 15 March 2011, Ralf Wildenhues wrote:
> Hi Stefano,
>
Hello Ralf.  I fear we'll have to agree to disagree on this issue (see
below).   Given that, I won't apply my patch (unless, of course, you
change your mind and decide to approve it anyway).

> * Stefano Lattarini wrote on Mon, Mar 14, 2011 at 12:51:29PM CET:
> >  <http://lists.gnu.org/archive/html/automake-patches/2011-03/msg00012.html>
> 
> > On Friday 04 March 2011, Stefano Lattarini wrote:
> > > On Friday 04 March 2011, Ralf Wildenhues wrote:
> > > > * Stefano Lattarini wrote on Fri, Mar 04, 2011 at 09:52:25AM CET:
> > > > > * tests/comments-in-var-defn.test: The configure.in stub created
> > > > > by default, which has the AC_INIT first argument obtained by the
> > > > > test name, causes autoconf 2.62 to fail with a spurious error
> > > > > message like: "configure.in:1: error: defn: undefined macro:".
> > > > > Thus, to prevent this, the test is renamed to ...
> [...]
> 
> > Subject: [PATCH] maintcheck: look for problematic names of testcases
> > 
> > The configure.in stub created by default by `tests/defs' obtains
> > the first argument of AC_INIT from the test name, and this can
> > cause some supported autoconf versions to fail with a spurious
> > error if that test name contains the name of an m4 builtin (e.g.,
> > `defn' or `undefine').
> > 
> > See for example the bug fixed by commit v1.11-287-g1325a8a.
> > 
> > This change add a maintainer check that warns about test names
> > which are possibly problematic in this regard.
> 
> Wouldn't it be easier to just require a fixed Autoconf version?
>
Unfortunately no, as also the latest version (2.68) is affected by
the bug; see my recent report to bug-autoconf:
 <http://blog.gmane.org/gmane.comp.sysutils.autoconf.bugs/day=20110315>

> Alternatively, if we can't do that: wouldn't it be more robust
> to let the defs.in machinery rename problematic names on the fly?
>
That smells like over-engineering to me; after all, up until today,
the problemtic test names have been 3 (sinclude.test, include.test,
comments-in-var-defn.test), in face of ~ 1000 tests.

> It's nicer to avoid bugs than having to work around them.
>
I have to say that, when it comes to error checking, I tend to prefer
automation that warns me noisily (+1 if it also offers advices) to
automation that tries to second-guess me behind my shoulders.  I find
the former simpler, more reliable, and mostly self-testing (I can
see a bogus error message right away, but I might fail to see a bogus
automatic workaround).

Regards,
  Stefano