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