Re: Warnings for excessive macro arguments

[Ralf Wildenhues]

Hello Eric,

* Eric Blake wrote on Mon, Aug 23, 2010 at 11:59:04PM CEST:
> Meanwhile, I don't see how warning on unexpected arguments is a
> problem - code that wants to be portable to both old and new
> autoconf will only use as many arguments as the old version
> supported.

Or try to use the new feature if available; but how can it know that it
is available?  I don't yet see how a feature check at m4 time would work
here.

> On the upgrade path, if 2.67 supports only ABC(arg1),
> but 2.68 supports ABC(arg1, arg2), then calling ABC(arg1, oops) in
> 2.67 would be a syntax warning, while in 2.68 it would silently
> assume you wanted to use the new argument feature.

Let's use a specific example:

  AC_INIT([Pkg], [1.0], [bug], [pkg], [website])

Do you think that 'autoconf-2.63 -Wall -Werror' should have errored out
for the website argument?  I'm not sure it should, and I don't think we
should promote non-Autoconf-Way code like

  m4_version_prereq([2.64],
    [AC_INIT([Pkg], [1.0], [bug], [pkg], [website])],
    [AC_INIT([Pkg], [1.0], [bug], [pkg])])

either (for the sake of the argument let's ignore the fact that various
bits and pieces of autotools still grep configure.ac for AC_INIT with
patterns that above would probably not match).

> But it does
> imply that to get the full benefit of those portability warnings
> that you would have to use the oldest version of autoconf that you
> plan to be portable to (but also one new enough that it actually
> detects and prints warnings in the first place).

But that's contrary to what we otherwise suggest to every user: to use
the most current set of autotools available, in order to get most fixes
and the most portability support out of the tools.

I acknowledge that there is a problem with typos and usage errors not
being detected by the current autoconf, but maybe we can find a way to
improve that while avoiding regressions for other good use cases.

Cheers,
Ralf