* Stefano Lattarini wrote on Tue, Mar 15, 2011 at 11:01:25AM CET: > Hello Ralf. I fear we'll have to agree to disagree on this issue (see > below).
No, we don't. So far, I've only asked questions. I haven't made up my mind yet. > Given that, I won't apply my patch (unless, of course, you > change your mind and decide to approve it anyway). Don't be discouraged up front, please. > On Tuesday 15 March 2011, Ralf Wildenhues wrote: > > * 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> > > > 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> So, can we just quote the argument so it's not detected by m4? me_quoted=`echo "$me" | sed 's,..,&@\&t@,g'` echo "AC_INIT([$me_quoted], [1.0])" ? If yes, why do you think that would be wrong, or over-engineering, to do this? > > 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. A three-line patch that avoids the problem for sure doesn't smell like over-engineering to me, when compared to a hundred-line patch that requires me to keep thinking about it in the future. > > 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. Who said something about second-guessing? Thanks, Ralf