[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
Karl Berry , Tue Sep 05 2023 23:15:16 GMT+0200 (Central European Summer Time) Karl: The same problem was also reported as bug 65730, with a patch Thanks Zack. I had just composed a reply saying just about exactly the same thing as you wrote :). I will merge the patches and try Bogdan's test, no problem. -k P.S. Bogdan, sorry that I wasn't thinking more clearly when I asked you to write the more complicated version. No problem, new "experience points" earned :). M4 and all Autoconf macros (knowledge about their existence) are still a bit out of my range. Especially AC_PROVIDE_IFELSE, which I don't even have in my Autoconf manual (it *is* found in the code, but not in the manual)... Bogdan
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
Karl: The same problem was also reported as bug 65730, with a patch Thanks Zack. I had just composed a reply saying just about exactly the same thing as you wrote :). I will merge the patches and try Bogdan's test, no problem. -k P.S. Bogdan, sorry that I wasn't thinking more clearly when I asked you to write the more complicated version.
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
> Karl Berry , Fri Sep 01 2023 00:28:04 GMT+0200 > (Central European Summer Time) >> Bogdan: I will adjust the patch, one way or another. Nothing more for >> you to do here after all :). --thanks, karl. Karl: The same problem was also reported as bug 65730, with a patch supplied by Łukasz Stelmach. That patch is preferable to Bogdan's patch, for two reasons. First, Łukasz's patch uses $@ to forward *all* arguments to AC_PROG_LEX, regardless of what they are, making it robust to the possibility of *more* arguments being added to AC_PROG_LEX in the future (for example, we might decide to add an option to specify that you need Flex specifically). Second, Łukasz's patch checks whether AC_PROG_LEX has already been invoked, and if so does not run it again. That makes the updated AM_PROG_LEX continue to be compatible with the workaround we (Autoconf) have been suggesting for this issue, namely to write AC_PROG_LEX([noyywrap]) AM_PROG_LEX It looks like Bogdan's patch does include a new set of tests that are worth preserving, but please use Łukasz's actual code change. (I regret I cannot volunteer to merge the two patches as I am in the middle of reinstalling the operating system on my workstation, and that's already taken a week and a half with no end in sight. You know how these things go, I'm sure.) zw
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
Karl Berry , Fri Sep 01 2023 00:28:04 GMT+0200
(Central European Summer Time)
One way to maintain compatibility
Thank you very much, Nick. That is all excellent to know.
Bogdan: I will adjust the patch, one way or another.
Nothing more for you to do here after all :). --thanks, karl.
Okay, no problem. Happy to have "triggered" this to move forward :)
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
One way to maintain compatibility Thank you very much, Nick. That is all excellent to know. Bogdan: I will adjust the patch, one way or another. Nothing more for you to do here after all :). --thanks, karl.
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
On 31/08/2023, Karl Berry wrote: > Hi Bogdan, > > In reference to: > https://lists.gnu.org/archive/html/automake/2023-07/msg7.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
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
Hi Bogdan, In reference to: https://lists.gnu.org/archive/html/automake/2023-07/msg7.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. I'm no expert on checking autoconf versions, but from glancing through the autoconf manual, it looks like m4_version_prereq might be the simplest to use in this case. It was officially added in ac 2.66, which should be old enough. It's described at the end of https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#Number-processing-Macros Wdyt? Can you tweak your patch along these lines? Thanks again, Karl
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
Hi.
In reference to:
https://lists.gnu.org/archive/html/automake/2023-07/msg7.html.
The attached patch allows the AM_PROG_LEX macro to accept
parameters, to accommodate for the fact that AC_PROG_LEX now (since
Autoconf 2.70) requires one. The values accepted by AM_PROG_LEX are
passed to AC_PROG_LEX the following way:
- an empty value is passed as empty, resulting in an Autoconf warning
(just like it is now),
- the word 'yywrap' is passed unchanged,
- the word 'noyywrap' is passed unchanged,
- the word 'empty' results in an empty value (and thus an Autoconf
warning)
- any other word results in a syntax warning and an empty value being
passed (resulting in an Autoconf warning).
Since it's Autoconf 2.70 that started using the parameter, I've
bumped the required value. You may change back if needed.
My M4 "knowledge" is simply basing on other examples and doing
whatever that doesn't result in an error, so you may change the code
as needed (m4_define, m4_warn, m4_expand).
Test for the parameters is added. All tests matching *lex*sh pass.
+11-20s to testing time.
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
From b159d82cb474d8ff4fc76e843b871a6d808e70bc Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Tue, 29 Aug 2023 20:31:55 +0200
Subject: [PATCH] Add params to AM_PROG_LEX
---
m4/lex.m4 | 15 ++-
t/lex-args.sh | 104 +
t/list-of-tests.mk | 1 +
3 files changed, 118 insertions(+), 2 deletions(-)
create mode 100644 t/lex-args.sh
diff --git a/m4/lex.m4 b/m4/lex.m4
index 7b0511526..bc3555773 100644
--- a/m4/lex.m4
+++ b/m4/lex.m4
@@ -10,10 +10,21 @@
# ---
# Autoconf leaves LEX=: if lex or flex can't be found. Change that to a
# "missing" invocation, for better error output.
+# Make sure to pass any supported parameters (since Autoconf 2.70).
AC_DEFUN([AM_PROG_LEX],
-[AC_PREREQ([2.50])dnl
+[AC_PREREQ([2.70])dnl
AC_REQUIRE([AM_MISSING_HAS_RUN])dnl
-AC_REQUIRE([AC_PROG_LEX])dnl
+m4_define([params], [])dnl
+m4_case([$1],
+ [], [m4_define([params], [])],
+ [yywrap], [m4_define([params], [yywrap])],
+ [noyywrap], [m4_define([params], [noyywrap])],
+ [empty],[m4_define([params], [])],
+ [m4_define([params], [])
+m4_warn([syntax], ['$0': calling AM_PROG_LEX with an unknown argument '$1'.
+You should use one of: 'yywrap', 'noyywrap', 'empty', or an empty value. Using an empty value.])])
+
+AC_PROG_LEX(m4_expand([params]))
if test "$LEX" = :; then
LEX=${am_missing_run}flex
fi])
diff --git a/t/lex-args.sh b/t/lex-args.sh
new file mode 100644
index 0..eea1e34f6
--- /dev/null
+++ b/t/lex-args.sh
@@ -0,0 +1,104 @@
+#! /bin/sh
+# Copyright (C) 2023 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see
