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
