On 31/08/2023, Karl Berry <k...@freefriends.org> wrote:
> Hi Bogdan,
>
> In reference to:
> https://lists.gnu.org/archive/html/automake/2023-07/msg00007.html.
>
> Thanks much!
>
> Since it's Autoconf 2.70 that started using the parameter, I've
> bumped the required value.
>
> I don't think we should require the brand-new ac 2.70 just for this
> minor feature. And I think it should be feasible not to: if the
> autoconf version is >= 2.70, your new code runs; if <2.70, just ignore
> any given argument. That way people can use the new automake macro with
> an older autoconf.
One way to maintain compatibility while ensuring the new options actually
are supported would be to just add the AC_PREREQ([2.70]) only in the cases
which actually trigger different behaviour in new Autoconf (i.e., the ones
that match yywrap and noyywrap options). Keep the old prereq unchanged
outside of the case.
That way, the minimum autoconf version requirement is only triggered
for autoconf inputs that actually attempt to use the new feature (by
explicitly passing yywrap or noyywrap options to AM_PROG_LEX).
To implement a "fall back to old behaviour with old autoconf, even if
the user explicitly selected the new behaviour", then you can just not
touch AC_PREREQ at all. There is no need for any version tests: old
versions of autoconf simply ignore any supplied arguments to
AC_PROG_LEX and always use the old behaviour.
Finally, one way to check whether AC_PROG_LEX accepts an argument is to
just use m4 to look for argument references in its definition, something
like:
m4_bmatch(m4_defn([AC_PROG_LEX]), [[$][1@*]],
[m4_errprintn([new lex macro])],
[m4_errprintn([old lex macro])])
then you don't need to test autoconf version numbers at all.
Cheers,
Nick
