Re: We can not run gnulib-tool in the MinGW.

[Paul Eggert]

On 7/4/24 04:26, anlex N wrote:

me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
$ ./gnulib-tool --list

I run this command in the gnulib source code, but have no output, why?


My guess is that you don't have Python installed, or it's installed but 
is missing some crucial component. If you have some expertise in MinGW 
- or learn it better, which would be a good idea if you really want to 
use gnulib-tool under MinGW - it would help if you could see exactly 
what went wrong.


Perhaps gnulib-tool should have better behavior in this situation, 
though as I don't use MinGW I can't advise how to modify gnulib-tool to 
do that.

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

I have two python:

angle-n@DESKTOP-5HNPO12 UCRT64 /e/workspace/github.com/gnu/gnulib
$ where python
E:\software\msys2\ucrt64\bin\python.exe
E:\software\msys2\usr\bin\python.exe

Although I uninstalled E:\software\msys2\ucrt64\bin\python.exe, I still can
not run.

What crucial component do you say? Paul.

On Thu, Jul 4, 2024 at 3:29 PM Paul Eggert  wrote:

> On 7/4/24 04:26, anlex N wrote:
> > me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
> > $ ./gnulib-tool --list
> >
> > I run this command in the gnulib source code, but have no output, why?
>
> My guess is that you don't have Python installed, or it's installed but
> is missing some crucial component. If you have some expertise in MinGW
> - or learn it better, which would be a good idea if you really want to
> use gnulib-tool under MinGW - it would help if you could see exactly
> what went wrong.
>
> Perhaps gnulib-tool should have better behavior in this situation,
> though as I don't use MinGW I can't advise how to modify gnulib-tool to
> do that.
>

Re: We can not run gnulib-tool in the MinGW.

[Collin Funk]

Paul Eggert  writes:

> My guess is that you don't have Python installed, or it's installed
> but is missing some crucial component. If you have some expertise in
> MinGW - or learn it better, which would be a good idea if you really
> want to use gnulib-tool under MinGW - it would help if you could see
> exactly what went wrong.

I don't think it a Python component could be missing. As long as a
Python version ≥ 3.7 is installed everything should be fine on that
end:

$ python3 --version
Python 3.12.3

Since everything we use is part of the Python standard library.

It could be possible that MinGW is missing required programs to run.
Although written in Python, it generally assumes everything listed in
DEPENDENCIES installed.

Off the top of my head I know certainly find, diff, patch, perl, make,
autoconf, and automake are needed for almost anything. There are a few
places sed is used. I'm probably missing more.

> Perhaps gnulib-tool should have better behavior in this situation,
> though as I don't use MinGW I can't advise how to modify gnulib-tool
> to do that.

Same, I don't know much about MinGW. I know that it should be possible
from Simon and Bruno's CI jobs. Personally I have run gnulib-tool using
Cygwin and everything was pretty straight forward. I would recommend
using that and installing all the packages listed in DEPENDENCIES.

Collin

Re: gitlog-to-changelog: Improve handling of time zones.

[Simon Josefsson via Gnulib discussion list]

Thanks for the patch!  I did not test it, but it looks safe from a
backwards compatibility point of view, so +1, and if this gets pushed I
will update some project to test it further.

/Simon


signature.asc
Description: PGP signature

Re: We can not run gnulib-tool in the MinGW.

[Simon Josefsson via Gnulib discussion list]

anlex N  writes:

> me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
> $ ./gnulib-tool --list
>
> I run this command in the gnulib source code, but have no output, why?

Could this be EOL character problem?  In one of my .gitlab-ci.yml files
I have needed to add this:

# 
https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings
# ./iconv_open-aix.gperf:27: warning: junk after %% is ignored
# ./iconv_open-aix.gperf:18: junk after declaration
file configure.ac
git config --global core.autocrlf false
git config --global core.eol lf
git rm -rf --cached . | tail
git reset --hard HEAD
file configure.ac

Maybe the problem is similar here.

/Simon


signature.asc
Description: PGP signature

Re: We can not run gnulib-tool in the MinGW.

[Jeffrey Walton]

On Wed, Jul 3, 2024 at 11:27 PM anlex N  wrote:
>
> me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
> $ ./gnulib-tool --list
>
> I run this command in the gnulib source code, but have no output, why?

In the past, I had problems compiling Rufus on MinGW, even though
Rufus specifically said to use MinGW.

I tracked it down to UCRT64. Pick one of the other ones in the Start
menu. I think there's about 5 of them, but the default is UCRT64.

Jeff

Re: We can not run gnulib-tool in the MinGW.

[Bruno Haible]

Hi Collin,

> It could be possible that MinGW is missing required programs to run.

Please be careful about the term. We need to distinguish
  * mingw - which is a toolchain (set of runtime libraries, together
with a customized GCC)
from
  * the development environments that people use. There are at least
- Cygwin with installed mingw-* packages,
- MSYS2,
- Debian/Ubuntu with cross tools, using WINE as intermediate layer
  for executing Windows binaries.

Here, the reporter is using MSYS2.

Bruno

Make time-stamp after-save-hooks buffer-local.

[Collin Funk]

Hi,

I complained awhile ago about the time stamps in Gnulib files. This was
because in my Emacs init file I have:

(setq enable-local-variables :safe)

Which allows Emacs to enable safe local variables but ignore unsafe ones
(mostly 'eval' AFAIK) instead of doing annoying popups every time.

As a side effect the lines in Gnulib files:

# eval: (add-hook 'before-save-hook 'time-stamp)

no longer worked. This issue could be fixed with:

(add-to-list 'safe-local-eval-forms
'(add-hook 'before-save-hook 'time-stamp))

I was originally confused because the default value of
'safe-local-eval-forms' has a different variation of that function call.
The reasoning is explained in the documentation for 'time-stamp':

> A time stamp can be automatically updated with current information
> every time you save a file.  To enable time-stamping for all files,
> customize option ‘before-save-hook’ or add this line to your init file:
> (add-hook 'before-save-hook 'time-stamp)
>
> To enable automatic time-stamping for only a specific file, add
> this line to a local variables list near the end of the file:
> eval: (add-hook 'before-save-hook 'time-stamp nil t)

I've confirmed this behavior and I think it is best not to mess with
users settings even if it is mostly harmless. Therefore I've applied the
attached patch.

Some files pulled from other places still have the "unsafe" version.
I've left them since they will get autoupdated anyways. But if anyone
wants to fix them:

$ grep -rl "'time-stamp)"
build-aux/mdate-sh
build-aux/install-sh
build-aux/mkinstalldirs
build-aux/config.guess
build-aux/config.sub
build-aux/compile
build-aux/depcomp
doc/maintain.texi
doc/standards.texi

Collin

>From 71dd87c3723e9c9dd3ae50d562b9ff04ff0ee660 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Thu, 4 Jul 2024 04:04:11 -0700
Subject: [PATCH] Make time-stamp after-save-hooks buffer-local.

* build-aux/announce-gen: Pass optional arguments to 'add-hook'.
* build-aux/bootstrap: Likewise.
* build-aux/do-release-commit-and-tag: Likewise.
* build-aux/gendocs.sh: Likewise.
* build-aux/git-version-gen: Likewise.
* build-aux/gitlog-to-changelog: Likewise.
* build-aux/gnu-web-doc-update: Likewise.
* build-aux/gnupload: Likewise.
* build-aux/move-if-change: Likewise.
* build-aux/prefix-gnulib-mk: Likewise.
* build-aux/update-copyright: Likewise.
* build-aux/useless-if-before-free: Likewise.
* build-aux/vc-list-files: Likewise.
* top/bootstrap: Likewise.
* top/bootstrap-funclib.sh: Likewise.
---
 ChangeLog   | 19 +++
 build-aux/announce-gen  |  4 ++--
 build-aux/bootstrap |  6 +++---
 build-aux/do-release-commit-and-tag |  4 ++--
 build-aux/gendocs.sh|  4 ++--
 build-aux/git-version-gen   |  4 ++--
 build-aux/gitlog-to-changelog   |  4 ++--
 build-aux/gnu-web-doc-update|  4 ++--
 build-aux/gnupload  |  4 ++--
 build-aux/move-if-change|  4 ++--
 build-aux/prefix-gnulib-mk  |  4 ++--
 build-aux/update-copyright  |  4 ++--
 build-aux/useless-if-before-free|  4 ++--
 build-aux/vc-list-files |  4 ++--
 top/bootstrap   |  4 ++--
 top/bootstrap-funclib.sh|  4 ++--
 16 files changed, 50 insertions(+), 31 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b19c2a482a..d480df5a25 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,22 @@
+2024-07-04  Collin Funk  
+
+	Make time-stamp after-save-hooks buffer-local.
+	* build-aux/announce-gen: Pass optional arguments to 'add-hook'.
+	* build-aux/bootstrap: Likewise.
+	* build-aux/do-release-commit-and-tag: Likewise.
+	* build-aux/gendocs.sh: Likewise.
+	* build-aux/git-version-gen: Likewise.
+	* build-aux/gitlog-to-changelog: Likewise.
+	* build-aux/gnu-web-doc-update: Likewise.
+	* build-aux/gnupload: Likewise.
+	* build-aux/move-if-change: Likewise.
+	* build-aux/prefix-gnulib-mk: Likewise.
+	* build-aux/update-copyright: Likewise.
+	* build-aux/useless-if-before-free: Likewise.
+	* build-aux/vc-list-files: Likewise.
+	* top/bootstrap: Likewise.
+	* top/bootstrap-funclib.sh: Likewise.
+
 2024-07-03  Collin Funk  
 
 	gitlog-to-changelog: Add a new --commit-timezone option.
diff --git a/build-aux/announce-gen b/build-aux/announce-gen
index f9e20129dd..9728aeee9e 100755
--- a/build-aux/announce-gen
+++ b/build-aux/announce-gen
@@ -35,7 +35,7 @@
 eval 'exec perl -wSx "$0" "$@"'
  if 0;
 
-my $VERSION = '2023-12-29 18:26'; # UTC
+my $VERSION = '2024-07-04 10:55'; # UTC
 # The definition above must lie within the first 8 lines in order
 # for the Emacs time-stamp write hook (at end) to update it.
 # If you change this file with Emacs, please let the write hook
@@ -695,7 +695,7 @@ EOF
 ## perl-label-offset: -2
 ## perl-extra-newline-before-brace: t
 ## perl-merge-trailing-else: nil
-## eval: (add-hook 'before-save-hook 'time-stamp)
+## eval: (add-hook 'bef

Re: We can not run gnulib-tool in the MinGW.

[Paul Eggert]

On 7/4/24 09:17, Collin Funk wrote:

As long as a
Python version ≥ 3.7 is installed everything should be fine on that
end:


Yes, though sometimes Python is misinstalled.

When I run "sh -x ./gnulib-tool --list", the last thing it does is:

exec /home/eggert/src/gnu/gnulib/./gnulib-tool.py --list

and when I run "sh -x /home/eggert/src/gnu/gnulib/./gnulib-tool.py 
--list", the last thing it does is:


exec python3 /home/eggert/src/gnu/gnulib-savannah/./.gnulib-tool.py --list

so there should be not much going on other than running Python. Perhaps 
the bug reporter could try running these "sh -x" commands and letting is 
know what happens.



PS. There's a lot of machinery in those shell scripts for the minor 
benefit of letting gnulib-tool be a symlink in your $PATH to the real 
gnulib-tool. How about if we drop support for this? That'd simplify 
startup quite a bit (if we're lucky it'll even fix the reporter's bug or 
at least make it easier to diagnose), and there is a better way to get 
the benefits of that minor feature that doesn't involve so much 
problematic shell rigamarole.


Something like the attached patch, perhaps? I haven't installed it.


PPS. Why do we have both gnulib-tool.py and .gnulib-tool.py? Is this 
commented in the source code?From 6e51dd21e8b62eb5dba5d2164d418fe22ee572a9 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 4 Jul 2024 13:19:23 +0200
Subject: [PATCH] gnulib-tool: simplify startup
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* gnulib-tool, gnulib-tool.py (func_readlink, func_gnulib_dir): Remove.
In main program, use shell substitution rather than external
programs, to reduce dependencies on external programs, to
simplify, and to speed things up a little.
* doc/gnulib-tool.texi (Invoking gnulib-tool): This means that we
no longer support the trick of putting a symlink to gnulib-tool
somewhere in your PATH, but it’s just as easy to put gnulib-tool
in your PATH so document that.
---
 ChangeLog|  12 +
 doc/gnulib-tool.texi |   6 +--
 gnulib-tool  | 113 ++-
 gnulib-tool.py   |  97 +++--
 4 files changed, 35 insertions(+), 193 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b19c2a482a..d9ddf46ce5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2024-07-04  Paul Eggert  
+
+	gnulib-tool: simplify startup
+	* gnulib-tool, gnulib-tool.py (func_readlink, func_gnulib_dir): Remove.
+	In main program, use shell substitution rather than external
+	programs, to reduce dependencies on external programs, to
+	simplify, and to speed things up a little.
+	* doc/gnulib-tool.texi (Invoking gnulib-tool): This means that we
+	no longer support the trick of putting a symlink to gnulib-tool
+	somewhere in your PATH, but it’s just as easy to put gnulib-tool
+	in your PATH so document that.
+
 2024-07-03  Collin Funk  
 
 	gitlog-to-changelog: Add a new --commit-timezone option.
diff --git a/doc/gnulib-tool.texi b/doc/gnulib-tool.texi
index 0f059e1287..a3b74830ef 100644
--- a/doc/gnulib-tool.texi
+++ b/doc/gnulib-tool.texi
@@ -24,11 +24,9 @@ simplifies the management of source files, @file{Makefile.am}s and
 contained in the @code{PATH} variable.  It needs to be run directly in
 the directory that contains the Gnulib source code.  You can do this
 either by specifying the absolute filename of @file{gnulib-tool}, or
-you can also use a symbolic link from a place inside your @code{PATH}
-to the @file{gnulib-tool} file of your preferred and most up-to-date
-Gnulib checkout, like this:
+by putting the Gnulib source code directory in your @env{PATH}, like this:
 @smallexample
-$ ln -s $HOME/gnu/src/gnulib.git/gnulib-tool $HOME/bin/gnulib-tool
+$ export PATH=$HOME/gnu/src/gnulib.git:$PATH
 @end smallexample
 
 Run @samp{gnulib-tool --help} for information.  To get familiar with
diff --git a/gnulib-tool b/gnulib-tool
index 789fe916a8..0737945b12 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -50,110 +50,21 @@ func_fatal_error ()
   func_exit 1
 }
 
-# func_readlink SYMLINK
-# outputs the target of the given symlink.
-if (type readlink) > /dev/null 2>&1; then
-  func_readlink ()
-  {
-# Use the readlink program from GNU coreutils.
-readlink "$1"
-  }
-else
-  func_readlink ()
-  {
-# Use two sed invocations. A single sed -n -e 's,^.* -> \(.*\)$,\1,p'
-# would do the wrong thing if the link target contains " -> ".
-LC_ALL=C ls -l "$1" | sed -e 's, -> ,#%%#,' | sed -n -e 's,^.*#%%#\(.*\)$,\1,p'
-  }
-fi
-
-# func_gnulib_dir
-# locates the directory where the gnulib repository lives
-# Input:
-# - progname name of this program
-# Sets variables
-# - self_abspathname absolute pathname of gnulib-tool
-# - gnulib_dir   absolute pathname of gnulib repository
-func_gnulib_dir ()
-{
-  case "$progname" in
-/* | ?:*) self_abspathname="$progname" ;;
-*/*) self_abspathname=`pwd`/"$progname" 

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

Hello Simon, the problem is not like you say. so sad.

On Thu, Jul 4, 2024 at 4:26 PM Simon Josefsson  wrote:

> anlex N  writes:
>
> > me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
> > $ ./gnulib-tool --list
> >
> > I run this command in the gnulib source code, but have no output, why?
>
> Could this be EOL character problem?  In one of my .gitlab-ci.yml files
> I have needed to add this:
>
> #
> https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings
> # ./iconv_open-aix.gperf:27: warning: junk after %% is ignored
> # ./iconv_open-aix.gperf:18: junk after declaration
> file configure.ac
> git config --global core.autocrlf false
> git config --global core.eol lf
> git rm -rf --cached . | tail
> git reset --hard HEAD
> file configure.ac
>
> Maybe the problem is similar here.
>
> /Simon
>

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

Hello Jeffrey, what do you mean? I don't understand what you're saying.
msys2.exe, ucrt64.exe, clang64.exe, mingw64.exe environment can not
built it at all.

On Thu, Jul 4, 2024 at 5:59 PM Jeffrey Walton  wrote:

> On Wed, Jul 3, 2024 at 11:27 PM anlex N  wrote:
> >
> > me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
> > $ ./gnulib-tool --list
> >
> > I run this command in the gnulib source code, but have no output, why?
>
> In the past, I had problems compiling Rufus on MinGW, even though
> Rufus specifically said to use MinGW.
>
> I tracked it down to UCRT64. Pick one of the other ones in the Start
> menu. I think there's about 5 of them, but the default is UCRT64.
>
> Jeff
>

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

I follow Paul Eggert's steps:

me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
$ sh -x ./gnulib-tool --create-testdir --dir=/tmp/testdirr --verbose terminfo
+ progname=./gnulib-tool
+ func_gnulib_dir
+ case "$progname" in
++ pwd
+ self_abspathname=/e/workspace/github.com/gnu/gnulib/./gnulib-tool
+ test -h /e/workspace/github.com/gnu/gnulib/./gnulib-tool
++ echo /e/workspace/github.com/gnu/gnulib/./gnulib-tool
++ sed -e 's,/[^/]*$,,'
+ gnulib_dir=/e/workspace/github.com/gnu/gnulib/.
+ case "$GNULIB_TOOL_IMPL" in
+ exec /e/workspace/github.com/gnu/gnulib/./gnulib-tool.py
--create-testdir --dir=/tmp/testdirr --verbose terminfo
Module list with included dependencies (indented):
absolute-header
alignasof
alignasof-tests
assert-h
assert-h-tests
attribute
c-ctype
c-ctype-tests
c99
ctype
ctype-tests
extensions
extern-inline
gen-header
havelib
include_next
intprops
intprops-tests
inttypes
inttypes-incomplete
inttypes-tests
isblank
isblank-tests
limits-h
limits-h-tests
multiarch
snippet/_Noreturn
snippet/arg-nonnull
snippet/c++defs
snippet/warn-on-use
ssize_t
std-gnu11
stdbool
stdbool-tests
stddef
stddef-tests
stdint
stdint-tests
stdlib
stdlib-tests
sys_types
sys_types-tests
  terminfo
terminfo-h
terminfo-tests
test-framework-sh
test-framework-sh-tests
unistd
unistd-tests
verify
verify-tests
wchar
wchar-tests
File list:
  build-aux/config.rpath
  lib/_Noreturn.h
  lib/arg-nonnull.h
  lib/assert.in.h
  lib/attribute.h
  lib/c++defs.h
  lib/c-ctype.c
  lib/c-ctype.h
  lib/ctype.in.h
  lib/intprops-internal.h
  lib/intprops.h
  lib/inttypes.in.h
  lib/isblank.c
  lib/limits.in.h
  lib/stddef.in.h
  lib/stdint.in.h
  lib/stdlib.in.h
  lib/sys_types.in.h
  lib/terminfo.h
  lib/tparm.c
  lib/tputs.c
  lib/unistd.c
  lib/unistd.in.h
  lib/verify.h
  lib/warn-on-use.h
  lib/wchar.in.h
  m4/00gnulib.m4
  m4/absolute-header.m4
  m4/assert_h.m4
  m4/c-bool.m4
  m4/codeset.m4
  m4/ctype_h.m4
  m4/curses.m4
  m4/extensions.m4
  m4/extern-inline.m4
  m4/gnulib-common.m4
  m4/host-cpu-c-abi.m4
  m4/include_next.m4
  m4/inttypes.m4
  m4/isblank.m4
  m4/lib-ld.m4
  m4/lib-link.m4
  m4/lib-prefix.m4
  m4/limits-h.m4
  m4/locale-fr.m4
  m4/multiarch.m4
  m4/off64_t.m4
  m4/off_t.m4
  m4/pid_t.m4
  m4/ssize_t.m4
  m4/std-gnu11.m4
  m4/stdalign.m4
  m4/stddef_h.m4
  m4/stdint.m4
  m4/stdlib_h.m4
  m4/sys_types_h.m4
  m4/terminfo.m4
  m4/unistd_h.m4
  m4/warn-on-use.m4
  m4/wchar_h.m4
  m4/wchar_t.m4
  m4/wint_t.m4
  m4/zzgnulib.m4
  tests/init.sh
  tests/macros.h
  tests/signature.h
  tests/test-alignasof.c
  tests/test-assert.c
  tests/test-c-ctype.c
  tests/test-ctype.c
  tests/test-init.sh
  tests/test-intprops.c
  tests/test-inttypes.c
  tests/test-isblank.c
  tests/test-limits-h.c
  tests/test-stdbool.c
  tests/test-stddef.c
  tests/test-stdint.c
  tests/test-stdlib.c
  tests/test-sys_types.c
  tests/test-sys_wait.h
  tests/test-terminfo.c
  tests/test-unistd.c
  tests/test-verify-try.c
  tests/test-verify.c
  tests/test-verify.sh
  tests/test-wchar.c
executing aclocal -I glm4
executing autoconf
executing autoheader
executing touch config.h.in
executing automake --add-missing --copyconfigure.ac:8: installing
'build-aux/compile'configure.ac:4: installing
'build-aux/install-sh'configure.ac:4: installing 'build-aux/missing'
gllib/Makefile.am: installing 'build-aux/depcomp'
executing aclocal -I ../glm4
executing autoconf
executing autoheader
executing touch config.h.in
executing automake --add-missing --copy
parallel-tests: installing '../build-aux/test-driver'
patching file build-aux/test-driver
/e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** could not patch
test-driver script
/e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** Stop.

*could not patch test-driver script*, so crazy, I am very painful, friends,
do you know?

On Thu, Jul 4, 2024 at 7:38 PM Paul Eggert  wrote:

> On 7/4/24 09:17, Collin Funk wrote:
> > As long as a
> > Python version ≥ 3.7 is installed everything should be fine on that
> > end:
>
> Yes, though sometimes Python is misinstalled.
>
> When I run "sh -x ./gnulib-tool --list", the last thing it does is:
>
> exec /home/eggert/src/gnu/gnulib/./gnulib-tool.py --list
>
> and when I run "sh -x /home/eggert/src/gnu/gnulib/./gnulib-tool.py
> --list", the last thing it does is:
>
> exec python3 /home/eggert/src/gnu/gnulib-savannah/./.gnulib-tool.py --list
>
> so there should be not much going on other than running Python. Perhaps
> the bug reporter could try running these "sh -x" commands and letting is
> know what happens.
>
>
> PS. There's a lot of machinery in those shell scripts for the minor
> benefit of letting gnulib-tool be a symlink in your $PATH to the real
> gnulib-tool. How about if we drop support for this? That'd simplify
> startup quite a bit (if we're lucky it'll even fix the reporter

Re: We can not run gnulib-tool in the MinGW.

[Paul Eggert]

On 7/4/24 14:08, anlex N wrote:

I follow Paul Eggert's steps:

me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
$ sh -x ./gnulib-tool --create-testdir --dir=/tmp/testdirr --verbose terminfo


Oh, I meant for you to run

sh -x ./gnulib-tool --list

as I thought you said that even a simple --list didn't work. However, it 
seems that in this run you got further than before so perhaps you fixed 
something.




/e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** could not patch
test-driver script
/e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** Stop.


Unfortunately the Python version of gnulib-tool doesn't have a readymade 
debugging option like 'sh -x' to see what went wrong.


But do you have the 'patch' program installed? If not, that might 
explain the problem. Please check all the programs listed in 
DEPENDENCIES and make sure they're all installed.



As an aside to Collin, I see that patching is done via subprocess.call. 
Since we're assuming Python 3.7 or later, shouldn't gnulib-tool.py be 
using subprocess.run instead?  That's what the Python documentation 
recommends, and that way we could capture stderr and report it to the 
user, which would help debug problems like this.

Re: We can not run gnulib-tool in the MinGW.

[Bruno Haible]

anlex N wrote:
> patching file build-aux/test-driver
> /e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** could not patch
> test-driver script
> /e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** Stop.

I would guess that you don't have a 'patch' program in your PATH.
Try
  $ type patch
  $ type patch.exe

And review the DEPENDENCIES file, to see whether you are missing some
other programs.

Bruno

Re: symlinks to programs

[Bruno Haible]

Paul Eggert wrote:
> PS. There's a lot of machinery in those shell scripts for the minor 
> benefit of letting gnulib-tool be a symlink in your $PATH to the real 
> gnulib-tool. How about if we drop support for this?

This is not a "minor" benefit, but a major one.

  1) It's documented:
 


  2) If it was not present, the user would have to write a shell-script wrapper;
 however, some users are not proficient enough with shell scripting ('exec',
 "$@", etc.) to be able to write such a wrapper.

  3) The GNU Coding Standards
 
 also say that programs should handle this case:
   "If the invocation directory doesn’t contain what’s needed, but
the executable file name is a symbolic link, the program should
try using the link target’s containing directory as the invocation
directory."

On POSIX systems, users are supposed to be able to use symlinks for data
files - with no need to write a Hurd translator. And likewise, users are
supposed to be able to use symlinks for programs - with no need to write
a shell script wrapper.

> That'd simplify startup quite a bit

It is sad that POSIX did not specify some shell built-ins (other than "$0")
that would make this task easy for shell scripts. (OK, they have added the
'readlink' program now in 2024. It's at least a start.) But it's the way it is,
and our solution is perfectly copy-and-pastable from one program to another.

I therefore vehemently disagree with your suggestion and patch.

> PPS. Why do we have both gnulib-tool.py and .gnulib-tool.py? Is this 
> commented in the source code?

Yes, there is a large comment about it in .gnulib-tool.py.

And why gnulib-tool.py is a shell script, not a Python script, is obvious
from what it contains:
  - It needs to find the invocation directory.
  - It needs to set environment variables for Python.
  - It may need to add command-line arguments for Python.
  - It provides a decent error message if Python is not found or too old.

Bruno

Re: symlinks to programs

[Paul Eggert]

On 7/4/24 20:17, Bruno Haible wrote:

Paul Eggert wrote:

PS. There's a lot of machinery in those shell scripts for the minor
benefit of letting gnulib-tool be a symlink in your $PATH to the real
gnulib-tool. How about if we drop support for this?


This is not a "minor" benefit, but a major one.

   1) It's documented:
  



Sure, but the proposed patch changes the documentation to say how to get 
the benefit in a better way.




   2) If it was not present, the user would have to write a shell-script 
wrapper;


No, there's no need to write a wrapper; see the proposed patch to the 
documentation. The new way is better than the old one, because it's a 
simpler shell command, it requires no change to the file system, and 
it'll work even on systems that don't support symlinks.




   3) The GNU Coding Standards


The part of the standard you quoted is intended to apply to GNU programs 
installed and used in the usual way. gnulib-tool is not such a program. 
It's not intended to be used anywhere other than the Gnulib source 
directory, and this reflects Gnulib's unusual role as a source-only library.


If people are actually using gnulib-tool via this symlink trick then we 
should keep supporting it. But I'm truly curious as to who they are and 
why they want to do that rather than the obvious thing.

Re: symlinks to programs

[Bruno Haible]

Paul Eggert wrote:
> >1) It's documented:
> >   
> > 
> 
> Sure, but the proposed patch changes the documentation to say how to get 
> the benefit in a better way.

No, it's not a "better way" to ask the user to add one more directory to his
PATH.

  1) Users should not need to extend their PATH for a single program.
 Because then, the PATH becomes more complicated and thus more
 prone to producing unexpected effects. (Similar to the CLASSPATH
 in Java. About 50% of issues in the Java world are CLASSPATH
 issues. Because for each installed package, CLASSPATH needs to
 be extended by 1 entry, typically.)

 Traditionally, every element of $PATH is for a _category_ of programs:
 The system maintenance tools, the applications, the games, the
 programs installed by the sysadmin, the programs installed by the
 user.

  2) It would cause constraints to ourselves: We could not have
 MODULES.html.sh, all-modules, check-copyright, etc. as programs
 at the top-level of gnulib. These programs are supposedly private
 to gnulib.

> gnulib-tool is not such a program. 
> It's not intended to be used anywhere other than the Gnulib source 
> directory, and this reflects Gnulib's unusual role as a source-only library.

But gnulib-tool is meant to be used from anywhere. Many packages use
the older approach of committing gnulib-cache.m4 under version control,
and the update command in this situation is just "gnulib-tool --update".

> If people are actually using gnulib-tool via this symlink trick then we 
> should keep supporting it.

The documentation has been describing this approach for 15 years.
Therefore it is guaranteed that a number of people use this symlink trick.

> But I'm truly curious as to who they are and 
> why they want to do that rather than the obvious thing.

My $HOME/bin/ directory has more than 20 symlinks, from 'shellcheck' to
'nyxt'. To me, that's the "obvious" thing, not adding 20 more directories
to PATH.

Bruno

Re: symlinks to programs

[Simon Josefsson via Gnulib discussion list]

Paul Eggert  writes:

> If people are actually using gnulib-tool via this symlink trick then
> we should keep supporting it. But I'm truly curious as to who they are
> and why they want to do that rather than the obvious thing.

The Debian gnulib package has a symlink in /usr/bin that goes to
/usr/share/gnulib, and there are several source packages that invoke
gnulib this way.  While this suggest the usage exists, I don't think it
necessarily means we must continue support it -- this symlink business
has always felt fragile and like a weird way of working to me.

Btw, there are many useful tools in gnulib/build-aux/ that are useful to
users and ought to be usable from /usr/bin on a system, and I've been
thinking about adding an extra Debian package like 'gnulib-utils' that
sets up the symlink (or not...) to below /usr/share/gnulib for the tools
that I can identify as generally useful.

/Simon


signature.asc
Description: PGP signature

Re: symlinks to programs

[Collin Funk]

Bruno Haible  writes:

>> If people are actually using gnulib-tool via this symlink trick then we 
>> should keep supporting it.
>
> The documentation has been describing this approach for 15 years.
> Therefore it is guaranteed that a number of people use this symlink trick.

FWIW I use it like this. I also have symlinks to gnulib-tool.sh and
gnulib-tool.py since they were easier to invoke than using the
environment variable. I think there was a short period of time that the
output wasn't diff'ed when using GNULIB_TOOL_IMPL.

Collin

Re: gitlog-to-changelog: Improve handling of time zones.

[Bruno Haible]

Collin Funk wrote:
> I've pushed the attached patch. Mostly the same as the original but the
> default behavior is unchanged.

Thanks a lot!

> The option is now named '--commit-timezone'. I'm not very creative so
> feel free to change it if you think of something better. :)

I had nothing better to suggest. Good choice :)

> I added documentation with an example where me and your time zones
> created unordered output in the generated ChangeLog:
> 
> 2024-06-19  Bruno Haible  
> 2024-06-18  Collin Funk  
> 2024-06-19  Bruno Haible  
> 
> Hopefully that should make it clear for anyone who wants to avoid that
> behavior.

The doc looks good, except there's no point in showing the bodies of the
three ChangeLog entries.

I like in particular that you start the description with
  "If you wish to output the @file{ChangeLog} with dates respecting the
   time zone each individual commit was made in you can use ..."
This is exactly right:
  * First, show *what* the user can achieve with a certain feature / why
they should use it.
  * Second, show *how* the user can achieve it.
Because it allows the user to stop reading once they know that is not
their goal / their use-case.


2024-07-04  Bruno Haible  

gitlog-to-changelog: Tweak documentation.
* doc/gitlog-to-changelog.texi (gitlog-to-changelog): Omit irrelevant
detail.

diff --git a/doc/gitlog-to-changelog.texi b/doc/gitlog-to-changelog.texi
index 2b96721e5d..6f1cabdcaf 100644
--- a/doc/gitlog-to-changelog.texi
+++ b/doc/gitlog-to-changelog.texi
@@ -61,31 +61,24 @@
 The use of @option{--commit-timezone} means that @file{ChangeLog} dates
 correctly represent when a committer pushed a change according to their
 time zone.  However, as a consequence @file{ChangeLog} dates will no
-longer be monotonically increasing.  This behavior may be undesired,
-especially when developers are spread across many different time zones.
+longer be monotonically increasing, if the developers are spread across
+different time zones.
 For example, the following three commits were made in a short period of
-time across two different time zones:
+time across two different time zones.
+This behavior may be undesired.
 
 @example
 2024-06-19  Bruno Haible  
 
-   filemode tests: Tweak.
-   * tests/test-filemode.c: Update comment.
-   * modules/filemode-tests (Depends-on): Add unistd.
+   ...
 
 2024-06-18  Collin Funk  
 
-   filemode: Add tests.
-   * modules/filemode-tests: New file.
-   * tests/test-filemode.c: New file.
+   ...
 
 2024-06-19  Bruno Haible  
 
-   copysignl tests: Avoid failure on Solaris 11.4.
-   * tests/test-copysignl.c: Include .
-   (LDBL_BYTES): New macro.
-   (main): Use it instead of sizeof (long double).
-   * modules/copysignl-tests (Depends-on): Add float.
+   ...
 @end example
 
 If you wish to limit the @file{ChangeLog} entries (perhaps for size

Re: gitlog-to-changelog: Improve handling of time zones.

[Collin Funk]

Bruno Haible  writes:

> The doc looks good, except there's no point in showing the bodies of the
> three ChangeLog entries.
>
> I like in particular that you start the description with
>   "If you wish to output the @file{ChangeLog} with dates respecting the
>time zone each individual commit was made in you can use ..."
> This is exactly right:
>   * First, show *what* the user can achieve with a certain feature / why
> they should use it.
>   * Second, show *how* the user can achieve it.
> Because it allows the user to stop reading once they know that is not
> their goal / their use-case.

Thanks for the feedback and improvements.

Collin

Re: symlinks to programs

[Paul Eggert]

On 7/4/24 21:49, Simon Josefsson wrote:

The Debian gnulib package has a symlink in /usr/bin that goes to
/usr/share/gnulib, and there are several source packages that invoke
gnulib this way.  While this suggest the usage exists, I don't think it
necessarily means we must continue support it -- this symlink business
has always felt fragile and like a weird way of working to me.


Yes it's fragile and weird, but people use it so that's a good argument 
for keeping it.

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

After install DEPENDENCIES in the gnulib source code, it can run:

hello@world UCRT64 /e/workspace/github.com/gnu/gnulib
$ ./gnulib-tool --create-testdir --dir=/tmp/my-testdir terminfo
Module list with included dependencies (indented):
absolute-header
alignasof
alignasof-tests
assert-h
assert-h-tests
attribute
c-ctype
c-ctype-tests
c99
ctype
ctype-tests
extensions
extern-inline
gen-header
havelib
include_next
intprops
intprops-tests
inttypes
inttypes-incomplete
inttypes-tests
isblank
isblank-tests
limits-h
limits-h-tests
multiarch
snippet/_Noreturn
snippet/arg-nonnull
snippet/c++defs
snippet/warn-on-use
ssize_t
std-gnu11
stdbool
stdbool-tests
stddef
stddef-tests
stdint
stdint-tests
stdlib
stdlib-tests
sys_types
sys_types-tests
  terminfo
terminfo-h
terminfo-tests
test-framework-sh
test-framework-sh-tests
unistd
unistd-tests
verify
verify-tests
wchar
wchar-tests
File list:
  build-aux/config.rpath
  lib/_Noreturn.h
  lib/arg-nonnull.h
  lib/assert.in.h
  lib/attribute.h
  lib/c++defs.h
  lib/c-ctype.c
  lib/c-ctype.h
  lib/ctype.in.h
  lib/intprops-internal.h
  lib/intprops.h
  lib/inttypes.in.h
  lib/isblank.c
  lib/limits.in.h
  lib/stddef.in.h
  lib/stdint.in.h
  lib/stdlib.in.h
  lib/sys_types.in.h
  lib/terminfo.h
  lib/tparm.c
  lib/tputs.c
  lib/unistd.c
  lib/unistd.in.h
  lib/verify.h
  lib/warn-on-use.h
  lib/wchar.in.h
  m4/00gnulib.m4
  m4/absolute-header.m4
  m4/assert_h.m4
  m4/c-bool.m4
  m4/codeset.m4
  m4/ctype_h.m4
  m4/curses.m4
  m4/extensions.m4
  m4/extern-inline.m4
  m4/gnulib-common.m4
  m4/host-cpu-c-abi.m4
  m4/include_next.m4
  m4/inttypes.m4
  m4/isblank.m4
  m4/lib-ld.m4
  m4/lib-link.m4
  m4/lib-prefix.m4
  m4/limits-h.m4
  m4/locale-fr.m4
  m4/multiarch.m4
  m4/off64_t.m4
  m4/off_t.m4
  m4/pid_t.m4
  m4/ssize_t.m4
  m4/std-gnu11.m4
  m4/stdalign.m4
  m4/stddef_h.m4
  m4/stdint.m4
  m4/stdlib_h.m4
  m4/sys_types_h.m4
  m4/terminfo.m4
  m4/unistd_h.m4
  m4/warn-on-use.m4
  m4/wchar_h.m4
  m4/wchar_t.m4
  m4/wint_t.m4
  m4/zzgnulib.m4
  tests/init.sh
  tests/macros.h
  tests/signature.h
  tests/test-alignasof.c
  tests/test-assert.c
  tests/test-c-ctype.c
  tests/test-ctype.c
  tests/test-init.sh
  tests/test-intprops.c
  tests/test-inttypes.c
  tests/test-isblank.c
  tests/test-limits-h.c
  tests/test-stdbool.c
  tests/test-stddef.c
  tests/test-stdint.c
  tests/test-stdlib.c
  tests/test-sys_types.c
  tests/test-sys_wait.h
  tests/test-terminfo.c
  tests/test-unistd.c
  tests/test-verify-try.c
  tests/test-verify.c
  tests/test-verify.sh
  tests/test-wchar.c
executing aclocal -I glm4
executing autoconf
executing autoheader
executing touch config.h.in
executing automake --add-missing --copyconfigure.ac:8: installing
'build-aux/compile'configure.ac:4: installing
'build-aux/install-sh'configure.ac:4: installing 'build-aux/missing'
gllib/Makefile.am: installing 'build-aux/depcomp'
executing aclocal -I ../glm4
executing autoconf
executing autoheader
executing touch config.h.in
executing automake --add-missing --copy
parallel-tests: installing '../build-aux/test-driver'
patching file build-aux/test-driver

But only /tmp folder can be run, or “not overwriting destination directory”
error still occurs, why?

On Fri, Jul 5, 2024 at 1:34 AM Bruno Haible  wrote:

> anlex N wrote:
> > patching file build-aux/test-driver
> > /e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** could not patch
> > test-driver script
> > /e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** Stop.
>
> I would guess that you don't have a 'patch' program in your PATH.
> Try
>   $ type patch
>   $ type patch.exe
>
> And review the DEPENDENCIES file, to see whether you are missing some
> other programs.
>
> Bruno
>
>
>
>

Re: We can not run gnulib-tool in the MinGW.

[Bruno Haible]

anlex N wrote:
> After install DEPENDENCIES in the gnulib source code, it can run:

Good!

> But only /tmp folder can be run, or “not overwriting destination directory”
> error still occurs, why?

Permission problems on Windows are hard to understand: The permissions
depend not only on the owner and permissions of the particular directory,
but also of all the ancestor directories of that directory.

I'd suggest to try Cygwin or WSL. They emulate a POSIX environment much
better than MSYS2; therefore you are much more likely to have positive
experiences with GNU software in these two environments.

Bruno

Re: We can not run gnulib-tool in the MinGW.

[Collin Funk]

Bruno Haible  writes:

>> But only /tmp folder can be run, or “not overwriting destination directory”
>> error still occurs, why?
>
> Permission problems on Windows are hard to understand: The permissions
> depend not only on the owner and permissions of the particular directory,
> but also of all the ancestor directories of that directory.

I don't think this is a permission issue. That error is expected when
passed a directory that already exists:

$ ./gnulib-tool --create-testdir --dir=/tmp/my-testdir terminfo

If the option passed to '--dir' exists then there will be an error.
Using that example:

$ gnulib-tool --create-testdir --dir=/tmp/my-testdir terminfo
$ gnulib-tool --create-testdir --dir=/tmp/my-testdir terminfo
/home/collin/.local/src/gnulib/gnulib-tool.py: *** not overwriting 
destination directory: /tmp/my-testdir
/home/collin/.local/src/gnulib/gnulib-tool.py: *** Stop.

This was a change we agreed upon a while ago since running
--create-testdir on an already existing testdir would break things,
IIRC.

> I'd suggest to try Cygwin or WSL. They emulate a POSIX environment much
> better than MSYS2; therefore you are much more likely to have positive
> experiences with GNU software in these two environments.

I have had good experiences with Cygwin, +1.

Collin

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

However, it can create in the /tmp folder, but can not build, so crazy:

hello@world UCRT64 /tmp/my-testdir2
$ MSYS2_ENV_CONV_EXCL=*
LDFLAGS=/e/workspace/github.com/gnu/ncurses/build/make/built/lib
./configure
configure: loading site script /etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in '/tmp/my-testdir2':
configure: error: C compiler cannot create executables
See 'config.log' for more details
hello@world UCRT64 /tmp/my-testdir2
$ cat config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by dummy configure 0, which was
generated by GNU Autoconf 2.72.  Invocation command line was

  $ ./configure

## - ##
## Platform. ##
## - ##

hostname = DOOR
uname -m = x86_64
uname -r = 3.5.3.x86_64
uname -s = MINGW64_NT-10.0-22631
uname -v = 2024-06-03 06:22 UTC

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = x86_64
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /ucrt64/bin/
PATH: /usr/local/bin/
PATH: /usr/bin/
PATH: /bin/
PATH: /c/Windows/System32/
PATH: /c/Windows/
PATH: /c/Windows/System32/Wbem/
PATH: /c/Windows/System32/WindowsPowerShell/v1.0/
PATH: /usr/bin/site_perl/
PATH: /usr/bin/vendor_perl/
PATH: /usr/bin/core_perl/

## --- ##
## Core tests. ##
## --- ##

configure:2904: loading site script /etc/config.site
| # This file is in public domain.
| # Original author: Karlson2k (Evgeny Grin)
| # Written for MSys2 to help running 'configure' scripts
|
| # Defaults for MSys2/MinGW64-targeted programs
|
| # Set proper selfname on bash and fallback to default name on other shells
| test -n "${BASH_SOURCE}" 2>/dev/null &&
config_site_me="${BASH_SOURCE[0]##*/}" || config_site_me=config.site
|
| # Set default 'host' to speedup configure
| if test -z "$build_alias"; then
|   build_alias="${MSYSTEM_CHOST}"  && \
| ${as_echo-echo} "$config_site_me:${as_lineno-$LINENO}: default
build_alias set to $build_alias" >&5
| fi
|
| # Set default 'prefix'
| if ( test -z "$prefix" || test "x$prefix" = "xNONE" ) && \
| ( test -z "$exec_prefix" || test "x$exec_prefix" = "xNONE" ); then
|   prefix="${MSYSTEM_PREFIX}" && \
| ${as_echo-echo} "$config_site_me:${as_lineno-$LINENO}: default
prefix set to $prefix" >&5
| fi
config.site:13: default build_alias set to x86_64-w64-mingw32
config.site:20: default prefix set to /ucrt64
configure:3287: looking for aux files: config.rpath config.guess
config.sub compile missing install-sh
configure:3300:  trying ./build-aux/
configure:3329:   ./build-aux/config.rpath found
configure:3329:   ./build-aux/config.guess found
configure:3329:   ./build-aux/config.sub found
configure:3329:   ./build-aux/compile found
configure:3329:   ./build-aux/missing found
configure:3311:   ./build-aux/install-sh found
configure:3460: checking for a BSD-compatible install
configure:3534: result: /usr/bin/install -c
configure:3545: checking whether build environment is sane
configure:3600: result: yes
configure:3761: checking for a race-free mkdir -p
configure:3804: result: /usr/bin/mkdir -p
configure:3811: checking for gawk
configure:3832: found /usr/bin/gawk
configure:3844: result: gawk
configure:3855: checking whether make sets $(MAKE)
configure:3879: result: yes
configure:3909: checking whether make supports nested variables
configure:3928: result: yes
configure:4131: checking for gcc
configure:4152: found /ucrt64/bin/gcc
configure:4164: result: gcc
configure:4523: checking for C compiler version
configure:4532: gcc --version >&5
gcc.exe (Rev3, Built by MSYS2 project) 14.1.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:4543: $? = 0
configure:4532: gcc -v >&5
Using built-in specs.
COLLECT_GCC=E:\software\msys2\ucrt64\bin\gcc.exe
COLLECT_LTO_WRAPPER=E:/software/msys2/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-14.1.0/configure --prefix=/ucrt64
--with-local-prefix=/ucrt64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/ucrt64/include
--libexecdir=/ucrt64/lib --enable-bootstrap --enable-checking=release
--with-arch=nocona --with-tune=generic
--enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,rust,jit
--enable-shared --enable-static --enable-libat