Re: We can not run gnulib-tool in the MinGW.
On 7/4/24 13:38, Paul Eggert wrote:
exec python3 /home/eggert/src/gnu/gnulib-savannah/./.gnulib-tool.py --list
Come to think of it, this can be simplifed to:
exec python3 ./.gnulib-tool.py --list
which avoids the overhead of computing and using the absolute file name.
This will be a minor win even after we get rid of the shell
implementation of gnulib-tool. I installed the attached to do that.From 15ec89beae6ded70d4079c5c49861d0b701a353b Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 6 Jul 2024 16:41:44 +0200
Subject: [PATCH] gnulib-tool: simplify/speed startup
* gnulib-tool, gnulib-tool.py (prog): New var. Use it to simplify
and speed up startup in common cases.
---
ChangeLog | 6 ++
gnulib-tool| 38 +++---
gnulib-tool.py | 16 ++--
3 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b68ed39449..340efb2de3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-07-06 Paul Eggert
+
+ gnulib-tool: simplify/speed startup
+ * gnulib-tool, gnulib-tool.py (prog): New var. Use it to simplify
+ and speed up startup in common cases.
+
2024-07-04 Bruno Haible
gitlog-to-changelog: Tweak documentation.
diff --git a/gnulib-tool b/gnulib-tool
index 789fe916a8..5cfc5bbb52 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -137,23 +137,35 @@ func_gnulib_dir ()
gnulib_dir=`echo "$self_abspathname" | sed -e 's,/[^/]*$,,'`
}
-func_gnulib_dir
+# If $progname contains '/' and is not a symlink, it suffices for $prog to be
+# the same as $progname with except with basename 'gnulib-tool’; this
+# speeds startup and might avoid problems in oddball development environments.
+# Otherwise, $prog is the absolute name of the gnulib-tool executable.
+if case $progname in
+ */*) test -h "$0" ;;
+ esac
+then
+ func_gnulib_dir
+ prog=$gnulib_dir/gnulib-tool
+else
+ prog=${progname%/*}/gnulib-tool
+fi
case "$GNULIB_TOOL_IMPL" in
'')
# Use the Python implementation if a suitable Python version is found
# in $PATH. This is the same Python version test as in gnulib-tool.py.
if (python3 -c 'import sys; sys.exit(not sys.version_info >= (3,7))') 2>/dev/null; then
- exec "$gnulib_dir/gnulib-tool.py" "$@"
+ exec "$prog.py" "$@"
else
echo "gnulib-tool: warning: python3 not found or too old, using the slow shell-based implementation" 1>&2
- exec "$gnulib_dir/gnulib-tool.sh" "$@"
+ exec "$prog.sh" "$@"
fi
;;
sh)
-exec "$gnulib_dir/gnulib-tool.sh" "$@" ;;
+exec "$prog.sh" "$@" ;;
py)
-exec "$gnulib_dir/gnulib-tool.py" "$@" ;;
+exec "$prog.py" "$@" ;;
sh+py)
case " $* " in
*" --import"* | *" --add-import"* | *" --remove-import"* | *" --update"* | *" --copy-file"*)
@@ -183,10 +195,14 @@ case "$GNULIB_TOOL_IMPL" in
func_exit 1
}
# Execute gnulib-tool.py in the clone directory.
-(cd "$tmp" && "$gnulib_dir/gnulib-tool.py" "$@" >"$tmp-py-out" 2>"$tmp-py-err")
+case $prog in
+ /*) absprog=$prog ;;
+ *) absprog=$PWD/prog ;;
+esac
+(cd "$tmp" && "$absprog.py" "$@" >"$tmp-py-out" 2>"$tmp-py-err")
pyrc=$?
# Execute gnulib-tool.sh in the current directory.
-"$gnulib_dir/gnulib-tool.sh" "$@" >"$tmp-sh-out" 2>"$tmp-sh-err"
+"$prog.sh" "$@" >"$tmp-sh-out" 2>"$tmp-sh-err"
shrc=$?
if test $shrc != 0; then
if test $pyrc = 0; then
@@ -233,10 +249,10 @@ case "$GNULIB_TOOL_IMPL" in
# Find another directory name.
tmp="$dir-glpy$$"
# Execute gnulib-tool.py, creating a different directory.
-"$gnulib_dir/gnulib-tool.py" "$@" --dir="$tmp" >"$tmp-py-out" 2>"$tmp-py-err"
+"$prog.py" "$@" --dir="$tmp" >"$tmp-py-out" 2>"$tmp-py-err"
pyrc=$?
# Execute gnulib-tool.sh, creating the intended directory.
-"$gnulib_dir/gnulib-tool.sh" "$@" >"$tmp-sh-out" 2>"$tmp-sh-err"
+"$prog.sh" "$@" >"$tmp-sh-out" 2>"$tmp-sh-err"
shrc=$?
if test $shrc != 0; then
if test $pyrc = 0; then
@@ -274,10 +290,10 @@ case "$GNULIB_TOOL_IMPL" in
# A gnulib-tool invocation that produces only output, no files.
tmp="glpy$$"
# Execute gnulib-tool.py.
-"$gnulib_dir/gnulib-tool.py" "$@" >"$tmp-py-out" 2>"$tmp-py-err"
+"$prog.py" "$@" >"$tmp-py-out" 2>"$tmp-py-err"
pyrc=$?
# Execute gnulib-tool.sh.
-"$gnulib_dir/gnulib-tool.sh" "$@" >"$tmp-sh-out" 2>"$tmp-sh-err"
+"$prog.sh" "$@" >"$tmp-sh-out" 2>"$tmp-sh-err"
shrc=$?
if test $shrc != 0; then
if test $pyrc = 0; then
diff --git a/gnulib-tool.py b/gnulib-tool.py
index 52389dcd78..bd13a8aa02 100755
--- a/gnulib-tool.py
+++ b/gnulib-tool.py
@@ -128,7 +128,19 @@
gnulib_dir=`echo "$self_abspathname" | sed -e 's,/[^/]*$,,'`
}
-func_gnulib_dir
+# If $progname contains '/' and is n
Re: We can not run gnulib-tool in the MinGW.
Paul Eggert wrote:
> On 7/4/24 13:38, Paul Eggert wrote:
>
> > exec python3 /home/eggert/src/gnu/gnulib-savannah/./.gnulib-tool.py --list
>
> Come to think of it, this can be simplifed to:
>
> exec python3 ./.gnulib-tool.py --list
>
> which avoids the overhead of computing and using the absolute file name.
The test suite still passes:
$ cd maint-tools/gnulib-tool-tests; ./test-all.sh
But are we OK to drop the ability to run gnulib-tool on Solaris 10?
The % operator used in the variable expansion ${progname%/*} is not
supported by Solaris 10 /bin/sh, see
column 4.
Bruno
Re: We can not run gnulib-tool in the MinGW.
On 7/6/24 17:07, Bruno Haible wrote: are we OK to drop the ability to run gnulib-tool on Solaris 10? I'm OK with it. When I deal with Solaris 10 (hey, our department's admin server is still Solaris 10 sparc!) I run gnulib-tool elsewhere and copy the results to Solaris 10. Does anybody do otherwise? Solaris 10 doesn't have Python 3; Python 2.6.4 (2009) is the default though Python 2.7.18 (2020) and Python 2.3.3 (2003) are also available. Since gnulib-tool's Python implementation requires Python 3.7 or later, Solaris 10 is already kinda on its last legs as far as gnulib-tool is concerned. If it's really necessary to support Solaris 10 sh we can still do it, at the cost of renaming .gnulib-tool.py to gnulib-tool.pydot or something like that. Not sure it's worth the hassle.
Re: We can not run gnulib-tool in the MinGW.
Paul Eggert wrote: > > are we OK to drop the ability to run gnulib-tool on Solaris 10? > > I'm OK with it. When I deal with Solaris 10 (hey, our department's admin > server is still Solaris 10 sparc!) I run gnulib-tool elsewhere and copy > the results to Solaris 10. Does anybody do otherwise? Likewise for me. > Solaris 10 doesn't have Python 3 Good point. So once we drop the shell-based implementation, Solaris 10 support will be already gone. So, let's drop Solaris 10 as platform for running gnulib-tool. Thanks. It's probably not even worth documenting in section "Target Platforms". Bruno
Re: We can not run gnulib-tool in the MinGW.
Bruno Haible writes: > Paul Eggert wrote: >> >> I'm OK with it. When I deal with Solaris 10 (hey, our department's admin >> server is still Solaris 10 sparc!) I run gnulib-tool elsewhere and copy >> the results to Solaris 10. Does anybody do otherwise? > > Likewise for me. +1 for not supporting running gnulib-tool on Solaris 10. I can't even ssh into the compile farm Solaris 10 machine without compiling a custom ssh client: $ ssh cfarm210.cfarm.net Bad server host key: Invalid key length The minimum key size was increased many years ago [1]. Collin [1] https://www.openssh.com/txt/release-7.6
ssh into Solaris 10 [was: We can not run gnulib-tool in the MinGW.]
On 7/6/24 23:52, Collin Funk wrote: I can't even ssh into the compile farm Solaris 10 machine without compiling a custom ssh client: $ ssh cfarm210.cfarm.net Bad server host key: Invalid key length Don't know what OpenSSH version you normally run, but with OpenSSH_9.6p1 this configuration works for me: Host cfarm210 HostName %h.cfarm.net HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa RequiredRSASize 1024 KexAlgorithms +diffie-hellman-group1-sha1 With OpenSSH_8.9p1 I omit the RequiredRSASize line. Isn't SSH configuration wonderful?
Re: ssh into Solaris 10 [was: We can not run gnulib-tool in the MinGW.]
Hi Paul, Paul Eggert writes: > Don't know what OpenSSH version you normally run, but with > OpenSSH_9.6p1 this configuration works for me: > > Host cfarm210 > HostName %h.cfarm.net > HostKeyAlgorithms +ssh-rsa > PubkeyAcceptedAlgorithms +ssh-rsa > RequiredRSASize 1024 > KexAlgorithms +diffie-hellman-group1-sha1 > > With OpenSSH_8.9p1 I omit the RequiredRSASize line. Ah, thanks! The "RequiredRSASize 1024" line fixed it for me too. On Fedora 40 it is set to 2048 in /etc/crypto-policies/back-ends/openssh.config. Originally I thought it was a short RSA key allowed by now outdated ssh versions. > Isn't SSH configuration wonderful? Probably a lack of me reading in this case. :) Collin
pthread-cond: Fix compilation error on native Windows
Building a testdir for module 'pthread-rwlock' on mingw, I see a compilation error: ../../gllib/pthread-cond.c:25:29: fatal error: windows-thread.h: No such file or directory # include "windows-thread.h" ^ compilation terminated. make[4]: *** [Makefile:2144: pthread-cond.o] Error 1 This patch fixes it. 2024-07-06 Bruno Haible pthread-cond: Fix compilation error on native Windows. * lib/pthread-cond.c: Include windows-cond.h, not windows-thread.h. diff --git a/lib/pthread-cond.c b/lib/pthread-cond.c index 380cdfd357..ca22e0373b 100644 --- a/lib/pthread-cond.c +++ b/lib/pthread-cond.c @@ -22,7 +22,7 @@ #include #if (defined _WIN32 && ! defined __CYGWIN__) && USE_WINDOWS_THREADS -# include "windows-thread.h" +# include "windows-cond.h" #else # include # include
