Re: [PATCH] gnulib-tool.py: Fix write failure due to bad sourcebase.

2024-03-14 Thread Bruno Haible
Hi Collin, > This patch should fix gnulib-tool.py when running > 'gnulib-tool.py --add-import' in OATH Toolkit. > > It appears that gnulib-tool.py was not picking up the m4 directories > correctly. This means that when the GLImport object was created it > could not find the gnulib-cache.m4 file

Re: [PATCH] gnulib-tool.py: Fix write failure due to bad sourcebase.

2024-03-14 Thread Collin Funk
Hi Bruno, On 3/14/24 7:38 AM, Bruno Haible wrote: > This patch looks better than the previous one, that added a > setSourceBase('lib') invocation. Applied. Thanks! Yes, that was more just me trying to explain the cause of the issue. I didn't have a good solution at the time. This patch was

Re: planning for beta-testing gnulib-tool.py

2024-03-14 Thread Collin Funk
Hi Bruno, On 3/10/24 8:59 AM, Bruno Haible wrote: > 4) There is a list of packages that use gnulib, in the file users.txt. >We can pick, say, the 10 most important or most active GNU packages among >these, and repeat step 3) for each of them. I am still working on gnulib-tool.py.TODO and

Re: planning for beta-testing gnulib-tool.py

2024-03-14 Thread Darshit Shah
Hi Bruno and Colin, I'm following the development of gnulib-tool.py pretty closely. Wget and Wget2 have tried to use the Python version multiple times in the past with varying levels of success. I'll volunteer my time for using GNU Wget and Wget2 as initial beta testers of the new Python

gnulib-tool: Obey environment variable GNULIB_TOOL_IMPL

2024-03-14 Thread Bruno Haible
Collin Funk wrote: > I like the plan of picking ~10 GNU packages and think it is a good > starting point that we can adjust if needed. Since the process is > useful for me anyways, I think it is best that go through the list of > packages in users.txt and try building them. OK. If you start to go

Re: gnulib-tool: Obey environment variable GNULIB_TOOL_IMPL

2024-03-14 Thread Collin Funk
Hi Bruno, On 3/14/24 2:22 PM, Bruno Haible wrote: > OK. If you start to go into this direction, it is time for me to > implement the GNULIB_TOOL_IMPL=sh+py option. Done through the patch below. Oops, I didn't mean to rush you... I was just changing a few lines of the boostrap script by hand.

[PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 57.

2024-03-14 Thread Collin Funk
This patch implements the --extract-recursive-link-directive and --extract-recursive-link-directive options. For --extract-recursive-dependencies, the 'canonicalize' macro seemed to work well since it has many dependencies: $ gnulib-tool.py --extract-recursive-dependencies canonicalize >

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 57.

2024-03-14 Thread Bruno Haible
Hi Collin, > This patch implements the --extract-recursive-link-directive and > --extract-recursive-link-directive options. Thanks! Applied, with a tiny comment change: I removed the dollars from # Remove $handledmodules from $inmodules. Bruno

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 57.

2024-03-14 Thread Collin Funk
Hi Bruno, On 3/14/24 7:23 PM, Bruno Haible wrote: > Thanks! Applied, with a tiny comment change: I removed the dollars from > # Remove $handledmodules from $inmodules. Oops, in the commit before I added some comments directly from gnulib-tool to main.py as well. Feel free to change them if