[bug#71425] test: Accommodate C23 compilers.
In the yacc test I see warnings like this:
main.c:4:10: error: implicit declaration of function ‘yyparse’
[-Wimplicit-function-declaration]
4 | return yyparse ();
| ^~~
and some for yylex which is declared, but with an empty parameter list
instead of void.
I assume this is because GCC becoming more strict to conform with C23
requirements. I did these tests with GCC 14.1.
I have attached a patch fixing these tests on my system.
Collin
>From 615faf791ccc2aa744c61bd9f5982ebe225748d4 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Fri, 7 Jun 2024 21:53:51 -0700
Subject: [PATCH] test: Accommodate C23 compilers.
* t/yacc-deleted-headers.sh: Declare yyparse before use.
* t/yacc-depend.sh: Likewise.
* t/yacc-mix-c-cxx.sh: Likewise.
* t/yacc-d-basic.sh: Likewise. Use void instead of empty parameter list.
* t/yacc-depend2.sh: Likewise.
---
t/yacc-d-basic.sh | 3 ++-
t/yacc-deleted-headers.sh | 1 +
t/yacc-depend.sh | 1 +
t/yacc-depend2.sh | 3 ++-
t/yacc-mix-c-cxx.sh | 2 ++
5 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/t/yacc-d-basic.sh b/t/yacc-d-basic.sh
index cc076148b..df3cfece1 100644
--- a/t/yacc-d-basic.sh
+++ b/t/yacc-d-basic.sh
@@ -49,7 +49,7 @@ cp foo/Makefile.am baz/Makefile.am
cat > foo/parse.y << 'END'
%{
#include "parse.h"
-int yylex () { return 0; }
+int yylex (void) { return 0; }
void yyerror (const char *s) {}
%}
%%
@@ -69,6 +69,7 @@ sed -e 's/parse\.h/y.tab.h/' bar/parse.y
cat > foo/main.c << 'END'
#include "parse.h"
+extern int yyparse (void);
int main ()
{
return yyparse ();
diff --git a/t/yacc-deleted-headers.sh b/t/yacc-deleted-headers.sh
index 81957eb86..682dd5f5d 100644
--- a/t/yacc-deleted-headers.sh
+++ b/t/yacc-deleted-headers.sh
@@ -68,6 +68,7 @@ END
cat > main1.c << 'END'
#include "parse1.h"
+extern int yyparse (void);
int main (void)
{
return ZARDOZ + yyparse ();
diff --git a/t/yacc-depend.sh b/t/yacc-depend.sh
index e5ad6870c..1f67ecac4 100644
--- a/t/yacc-depend.sh
+++ b/t/yacc-depend.sh
@@ -48,6 +48,7 @@ END
cat > main.c << 'END'
#include "foo.h"
+extern int yyparse (void);
int main(void)
{
return yyparse ();
diff --git a/t/yacc-depend2.sh b/t/yacc-depend2.sh
index f0529294e..896b86df4 100644
--- a/t/yacc-depend2.sh
+++ b/t/yacc-depend2.sh
@@ -43,7 +43,7 @@ END
cat > foo.y << 'END'
%{
-int yylex () { return 0; }
+int yylex (void) { return 0; }
void yyerror (const char *s) {}
%}
%token TOKEN
@@ -54,6 +54,7 @@ END
cat > main.c << 'END'
#include "foo.h"
+extern int yyparse (void);
int main(void)
{
return yyparse ();
diff --git a/t/yacc-mix-c-cxx.sh b/t/yacc-mix-c-cxx.sh
index d454fe244..021b4223d 100644
--- a/t/yacc-mix-c-cxx.sh
+++ b/t/yacc-mix-c-cxx.sh
@@ -71,6 +71,7 @@ END
cat > 1.c <<'END'
#include "p.h"
+extern int yyparse (void);
int main ()
{
int new = ZARDOZ;
@@ -80,6 +81,7 @@ int main ()
END
cat > 2.c <<'END'
+extern int yyparse (void);
int main ()
{
int yyparse ();
--
2.45.2
[bug#71672] [PATCH] python: Prefer python3 over python
Hi, Shouldn't AM_PATH_PYTHON check for the python3 command before python? The full recommendation of how these should be setup is in PEP 394 [1]. On modern systems I don't think it should matter. On Fedora 40: $ command -v python /usr/bin/python $ command -v python3 /usr/bin/python3 $ python --version Python 3.12.3 $ python3 --version Python 3.12.3 The difference mostly exists on older machines. On CentOS 7.9 for example: $ command -v python /usr/bin/python $ command -v python3 /usr/bin/python3 $ python --version Python 2.7.5 $ python3 --version Python 3.6.8 I've attached a proposed path. I don't see a situation where a python3.* is installed without a python3 link. Therefore checking for python3 and fallingback on python seems reasonable to me. Collin [1] https://peps.python.org/pep-0394/From cd88a2461f0c89c2e70a7fc3a17058fb989313d4 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Thu, 20 Jun 2024 02:26:52 -0700 Subject: [PATCH] python: Prefer python3 over python * m4/python.m4 (AM_PATH_PYTHON): Check for python3 before python. * NEWS: Document that python3 is used first. --- NEWS | 2 +- m4/python.m4 | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 77347e5a3..99c562f15 100644 --- a/NEWS +++ b/NEWS @@ -7,7 +7,7 @@ New in 1.17: * New features added - - AM_PATH_PYTHON will, after checking "python", prefer any Python 3 + - AM_PATH_PYTHON will, after checking "python3", prefer any Python 3 version (latest versions checked first) over any Python 2 version. If a specific version of Python 2 is still needed, the $PYTHON variable should be set beforehand. diff --git a/m4/python.m4 b/m4/python.m4 index 0b1db2689..21116e1a3 100644 --- a/m4/python.m4 +++ b/m4/python.m4 @@ -37,7 +37,7 @@ AC_DEFUN([AM_PATH_PYTHON] dnl Find a Python interpreter. Python versions prior to 2.0 are not dnl supported. (2.0 was released on October 16, 2000). m4_define_default([_AM_PYTHON_INTERPRETER_LIST], -[python python3 dnl +[python3 python dnl python3.20 python3.19 python3.18 python3.17 python3.16 dnl python3.15 python3.14 python3.13 python3.12 python3.11 python3.10 dnl python3.9 python3.8 python3.7 python3.6 python3.5 python3.4 python3.3 dnl -- 2.45.2
[bug#71672] [PATCH] python: Prefer python3 over python
Karl Berry wrote: > I can imagine preferring "python3" to "python" in the future, but this > seems like too big of a change to make at the very end (I hope) of the > pretest cycle. I think it would be better to make it well in advance of > the next release and try to garner feedback on the inevitable problems > that will result. --thanks, karl. Sounds reasonable to me. It was just something I stumbled upon last night. I thought the intention was to prioritize python 3.X which would cause problems using "python" first. We can just leave this bug open or something until there is feedback and no release rush. Collin
[bug#71672] [PATCH] python: Prefer python3 over python
Hi Karl, Karl Berry wrote: > Yes ... but I feel strongly that we should try very hard not to break > existing configure setups. Reasonable goal. > It occurs to me that we could allow maintainers to specify p3-searching > options in their configure.ac, like > > AM_PYTHON_OPTS(python3-check-first python-check-omit) > > (Or additional args to AM_PATH_PYTHON, whatever.) > > That wouldn't have any compatibility issues, and would allow maintainers > to control what gets looked for, for packages that need to force python3. > (Other options could force looking for p2 first.) > > Would that make sense? Yes, I think that idea would work. Or maybe AM_PYTHON3_PATH which requires Python3 so that the interface of the original macro isn't changed. Do you have any ideas/opinions Zach? I don't ever use Python 2 so maybe my ideas for the interface are poor. Collin
[bug#71672] [PATCH] python: Prefer python3 over python
Zack Weinberg wrote: > Automake's python.m4 should also define these if they are not already defined. > Then, we split AM_PATH_PYTHON into the part that sets PYTHON, which is > implemented > in terms of the above macros (but still looks for both 2 and 3) and the part > that > does all the rest of it. People who want a slightly more efficient v3-only > configure > script can use AC_PATH_PYTHON3 + whatever the name of the new "all the rest > of it" > macro is. > > I think that should disentangle things reasonably well, but we should > definitely > do this early rather than late in an automake release cycle, and seek out > feedback > from existing users of AM_PATH_PYTHON. What say you? I like this idea and am happy to help after the upcoming release. Maybe something like: AM_PYTHON_SETUP([PYTHON-EXECUTABLE]) Which does all the extra $(pyexecdir), $(pkgpyexecdir), etc. given the python executable. It should be pretty simple to move all the code from AM_PATH_PYTHON to that separate macro since it should run on all supported versions of Python (2 and 3). Collin
[bug#73769] [PATCH] automake: distribute local gnulib directory modules
Hi Karl, Karl Berry writes: > What do others think? Bruno, would you mind taking a look at Michael's > message? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73769 I'm not Bruno, but I feel like I know a bit about gnulib-tool. :) I disagree with the patch since it doesn't work for every package that uses Gnulib. Specifically, it assumes the Makefile name 'gnulib.mk' which is used by Coreutils. In Coreutils' bootstrap.conf file we have: gnulib_tool_option_extras="--tests-base=gnulib-tests --with-tests --symlink\ --makefile-name=gnulib.mk --automake-subdir " The --makefile-name option is explained in gnulib-tool --help: --makefile-name=NAME Name of makefile in the source-base and tests-base directories (default "Makefile.am", or "Makefile.in" if --gnu-make). > Wouldn't it be cleaner if the packages that use gnulib take care to > include the gl/modules directory (and anything else needed)? Just like > anything else. This would be the correct way to do it, in my opinion. Collin
[bug#71672] [PATCH] python: Prefer python3 over python
Hi Karl, Karl Berry writes: > I'm hoping to put out the first pretest tomorrow and 1.18 not long > after. So clearly this Python stuff needs to wait for another release. Thanks for mentioning this again. That plan sounds fine. Python packages seem to have their own packaging stuff that works well so there is no rush. However, I still think these would be nice for projects that might use python scripts, etc. I had a look at implementing them yesterday, but my m4 talent is lacking. :) Collin
[bug#78525] [PATCH] test: Skip a test that fails without python enabled.
On a system without Python 't/py-compile-usage' fails with: + ./py-compile --help + cat stdout py-compile: Invalid python executable (according to -V): python py-compile: Python support disabled + test -s stderr + grep '^Usage: py-compile .' stdout + am_exit_trap 1 + exit_status=1 This occurs after the following commit: commit 0ea7ef97493cd88da915d1936e04a6ace5c754d8 Author: Karl Berry Date: Sun Feb 9 09:36:24 2025 -0800 python: restore more compatible behavior for $PYTHON. For https://bugs.gnu.org/74434. * lib/py-compile: if $PYTHON -V does not include the string "python" (case-insensitive), consider the support intentionally disabled and exit successfully, unless PYTHON is set to false, in which case exit unsuccessfully. This is closer to the old behavior. Mention this in the help message. * t/py-compile-env.sh: add test for PYTHON=:. * NEWS: mention this. (And, en passant, add some past bug#s and clarify that only RCS/SCCS pattern rules were disabled, not all.) Simple 1 line fix attached. :) Collin >From 5f9001d17fa17088468b650a26a6f876dcdca161 Mon Sep 17 00:00:00 2001 Message-ID: <5f9001d17fa17088468b650a26a6f876dcdca161.1747803682.git.collin.fu...@gmail.com> From: Collin Funk Date: Tue, 20 May 2025 22:00:13 -0700 Subject: [PATCH] test: Skip a test that fails without python enabled. * t/py-compile-usage.sh: Add 'required=python' before sourcing test-init.sh. --- t/py-compile-usage.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/py-compile-usage.sh b/t/py-compile-usage.sh index 0251a76a8..32dc44109 100644 --- a/t/py-compile-usage.sh +++ b/t/py-compile-usage.sh @@ -17,6 +17,7 @@ # Test 'py-compile --help', 'py-compile --version', and that 'py-compile' # correctly complains on wrong usage. +required=python . test-init.sh cp "$am_scriptdir/py-compile" . \ -- 2.49.0
[bug#78525] [PATCH] test: Skip a test that fails without python enabled.
Hi Karl, Karl Berry writes: > Installed and closing. Thanks Collin. > > BTW, do you have any idea why the "From " line in your patch is dated > from 2001? > From 5f9001d17fa17088468b650a26a6f876dcdca161 Mon Sep 17 00:00:00 2001 > > Doesn't matter. Just seemed curious. --thanks, karl. I generate my patches using 'git format-patch' [1]. So in this case when I have one patch I use the command 'git format-patch -1'. These patches can easily be applied with the correct author and such with 'git am' [2]. In this case as the Automake maintainer with commit access you can run: $ git am 0001-test-Skip-a-test-that-fails-without-python-enabled.patch $ git push And it will be correct assuming no merge conflicts or other issues. The date "Mon Sep 17 00:00:00 2001" is a magic date used by git [3]. Hopefully I explained that well enough. :) Collin [1] https://git-scm.com/docs/git-format-patch [2] https://git-scm.com/docs/git-am [3] https://github.com/git/git/blob/8613c2bb6cd16ef530dc5dd74d3b818a1ccbf1c0/mailinfo.c#L371C50-L371C73
[bug#78829] [PATCH] Silence 'time-stamp' warnings with bleeding-edge Emacs.
Hi Karl, I committed a similar patch to the attached one in Gnulib so I will copy my rational from there [1]: > I wanted to make a change to the bootstrap script but every time I saved > the file Emacs would open a new window with an annoying warning. This is > because of the following change documented in Emac's etc/NEWS: > > *** Some historical 'time-stamp' conversions now warn. > 'time-stamp-pattern' and 'time-stamp-format' had quietly accepted > several 'time-stamp' conversions (e.g., "%:y") that have been deprecated > since Emacs 27.1. These now generate a warning with a suggested > migration. > > Based on the 'git blame' it appears "%Y" was supported decades ago, so I > don't expect changing this to cause any trouble. Therefore, I have > pushed the attached patch. The old convention still exists in Gnulib files and files imported from other places. I have left them unchanged since we do not modify them and just modify them with 'make fetch'. Collin [1] https://lists.gnu.org/archive/html/bug-gnulib/2025-06/msg00093.html >From e136d117c387d2ad1c3d357ab24f7e287219e062 Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Wed, 18 Jun 2025 14:28:57 -0700 Subject: [PATCH] Silence 'time-stamp' warnings with bleeding-edge Emacs. * contrib/tap-driver.pl: Use "%Y" instead of "%:y" for the 'time-stamp-format' local variable. * lib/compile: Likewise. * lib/depcomp: Likewise. * lib/install-sh: Likewise. * lib/mdate-sh: Likewise. * lib/missing: Likewise. * lib/mkinstalldirs: Likewise. * lib/py-compile: Likewise. * lib/tap-driver.sh: Likewise. * lib/test-driver: Likewise. * lib/ylwrap: Likewise. --- contrib/tap-driver.pl | 4 ++-- lib/compile | 4 ++-- lib/depcomp | 4 ++-- lib/install-sh| 4 ++-- lib/mdate-sh | 4 ++-- lib/missing | 4 ++-- lib/mkinstalldirs | 4 ++-- lib/py-compile| 4 ++-- lib/tap-driver.sh | 4 ++-- lib/test-driver | 4 ++-- lib/ylwrap| 4 ++-- 11 files changed, 22 insertions(+), 22 deletions(-) diff --git a/contrib/tap-driver.pl b/contrib/tap-driver.pl index 8706deb92..b88b001c2 100755 --- a/contrib/tap-driver.pl +++ b/contrib/tap-driver.pl @@ -32,7 +32,7 @@ use Getopt::Long (); use TAP::Parser; -my $VERSION = '2025-01-31.17'; # UTC +my $VERSION = '2025-06-18.21'; # UTC my $ME = "tap-driver.pl"; @@ -558,7 +558,7 @@ main @ARGV; # eval: (add-hook 'before-save-hook 'time-stamp nil t) # time-stamp-line-limit: 50 # time-stamp-start: "my $VERSION = " -# time-stamp-format: "'%:y-%02m-%02d.%02H'" +# time-stamp-format: "'%Y-%02m-%02d.%02H'" # time-stamp-time-zone: "UTC0" # time-stamp-end: "; # UTC" # End: diff --git a/lib/compile b/lib/compile index c404e89e4..02ff093c3 100755 --- a/lib/compile +++ b/lib/compile @@ -1,7 +1,7 @@ #! /bin/sh # Wrapper for compilers which do not understand '-c -o'. -scriptversion=2025-02-03.05; # UTC +scriptversion=2025-06-18.21; # UTC # Copyright (C) 1999-2025 Free Software Foundation, Inc. # Written by Tom Tromey . @@ -358,7 +358,7 @@ exit $ret # sh-indentation: 2 # eval: (add-hook 'before-save-hook 'time-stamp nil t) # time-stamp-start: "scriptversion=" -# time-stamp-format: "%:y-%02m-%02d.%02H" +# time-stamp-format: "%Y-%02m-%02d.%02H" # time-stamp-time-zone: "UTC0" # time-stamp-end: "; # UTC" # End: diff --git a/lib/depcomp b/lib/depcomp index 1e2c35fad..9f6725b9e 100755 --- a/lib/depcomp +++ b/lib/depcomp @@ -1,7 +1,7 @@ #! /bin/sh # depcomp - compile a program generating dependencies as side-effects -scriptversion=2024-12-03.03; # UTC +scriptversion=2025-06-18.21; # UTC # Copyright (C) 1999-2025 Free Software Foundation, Inc. @@ -786,7 +786,7 @@ exit 0 # sh-indentation: 2 # eval: (add-hook 'before-save-hook 'time-stamp nil t) # time-stamp-start: "scriptversion=" -# time-stamp-format: "%:y-%02m-%02d.%02H" +# time-stamp-format: "%Y-%02m-%02d.%02H" # time-stamp-time-zone: "UTC0" # time-stamp-end: "; # UTC" # End: diff --git a/lib/install-sh b/lib/install-sh index 8a76989bb..1d8d96696 100755 --- a/lib/install-sh +++ b/lib/install-sh @@ -1,7 +1,7 @@ #!/bin/sh # install - install a program, script, or datafile -scriptversion=2024-12-03.03; # UTC +scriptversion=2025-06-18.21; # UTC # This originates from X11R5 (mit/util/scripts/install.sh), which was # later released in X11R6 (xc/config/util/install.sh) with the @@ -535,7 +535,7 @@ done # Local variables: # eval: (add-hook 'before-save-hook 'time-stamp nil t) # time-stamp-start: "scriptversion=" -# time-stamp-format: &q
