Re: symlinks to programs

[Paul Eggert]

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

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.


OK, but that comment explains why .gnulib-tool.py is separate from the 
main body of the Python program. But why are there two shell scripts 
gnulib-tool and gnulib-tool.py? Can't the latter be folded into the 
former? That would be simpler and faster.

Re: symlinks to programs

[Collin Funk]

Hi Paul,

Paul Eggert  writes:

> OK, but that comment explains why .gnulib-tool.py is separate from the
> main body of the Python program. But why are there two shell scripts
> gnulib-tool and gnulib-tool.py? Can't the latter be folded into the
> former? That would be simpler and faster.

I can have a look at removing it. It seems fairly simple.

Originally gnulib-tool.py was needed to deal with all the symlink
resolution to find $GNULIB_SRCDIR. Both Bruno and I didn't know much
about the 'import' feature of Python IIRC. The original solution
involved invoking python3 with the $PYTHONPATH enviornment variable.

The addition of .gnulib-tool.py means that $PYTHONPATH is no longer
needed.

Feel free to correct me on anything I said here Bruno.

Collin

Re: symlinks to programs

[Bruno Haible]

Paul Eggert wrote:
> But why are there two shell scripts 
> gnulib-tool and gnulib-tool.py? Can't the latter be folded into the 
> former? That would be simpler and faster.

This will be done when we drop support for the old shell-based
implementation and for the GNULIB_TOOL_IMPL environment variable.
In a year or so.

Until then, it is simpler to keep things as-is, because
  - In gnulib-tool, we have invocations of gnulib-tool.py at 3
different places.
  - There are error messages such as
  "gnulib-tool.py produced different files than gnulib-tool.sh! Compare 
`pwd` and $tmp."
When they occur, the user will need/want to run gnulib-tool.py
explicitly.

Sure, one could transform gnulib-tool.py into a shell function
in gnulib-tool. But what's the point, when it's only for a minimal
speedup and only for a limited time?

Bruno

Re: symlinks to programs

[Bruno Haible]

Collin Funk wrote:
> The addition of .gnulib-tool.py means that $PYTHONPATH is no longer
> needed.

Yes, I removed the use of PYTHONPATH in
.

Bruno

Re: gnulib-tool.py: Fix crash when no ACLOCAL_AMFLAGS is found.

[Paul Eggert]

On 6/2/24 14:51, Collin Funk wrote:

I don't know enough about Autotools to tell if anything silly can be
done using this trick. Not that you would run auto* in a project that
you don't trust anyways...


Right, but the glitch is worth documenting. I installed the attached 
into Autoconf.From 3a7aa01e2ada483c5790dc9ea1d761fd75248ff2 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 5 Jul 2024 20:32:40 +0100
Subject: [PATCH] doc: mention ACLOCAL_AMFLAGS and #

* doc/autoconf.texi: Mention that ACLOCAL_AMFLAGS
cannot use makefile comments.  Problem reported by
Collin Funk in:
https://lists.gnu.org/r/bug-gnulib/2024-06/msg5.html
---
 doc/autoconf.texi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index cb148398..ee3f2f7a 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -1821,7 +1821,8 @@ If you want @command{autoreconf} to pass flags that are not listed here
 on to @command{aclocal}, set @code{ACLOCAL_AMFLAGS} in your @file{Makefile.am}.
 Due to a limitation in the Autoconf implementation these flags currently
 must be set on a single line in @file{Makefile.am}, without any
-backslash-newlines.  Also, be aware that future Automake releases might
+backslash-newlines or makefile comments.
+Also, be aware that future Automake releases might
 start flagging @code{ACLOCAL_AMFLAGS} as obsolescent, or even remove
 support for it.
 
@@ -2171,7 +2172,7 @@ Note that if you use @command{aclocal} from an Automake release prior to
 in your top-level @file{Makefile.am}.  Due to a limitation in
 the Autoconf implementation of @command{autoreconf}, these include
 directives currently must be set on a single line in @file{Makefile.am},
-without any backslash-newlines.
+without any backslash-newlines or makefile comments.
 @end defmac
 
 @prindex @command{config.guess}
-- 
2.45.2

Re: gnulib-tool.py: Fix crash when no ACLOCAL_AMFLAGS is found.

[Collin Funk]

Paul Eggert  writes:

> Right, but the glitch is worth documenting. I installed the attached
> into Autoconf.

Thanks!

Collin