Re: debugging gnulib-tool.py

On 3/15/24 5:27 PM, Bruno Haible wrote: > * Choice: It seems that PyCharm, VSCode, Spyder, Eclipse with PyDev are the > most prominent candidates. I used PyCharm for a course I took in college since the professor wanted us to. I remember liking it. It seems that the source of the PyCharm

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

Hi Bruno, On 3/15/24 6:09 PM, Bruno Haible wrote: > To make these two options interfere with each other, so that the last one > wins, how about using the same variable for both? Well, now I feel silly... Let me know how this looks. I've imported CopyAction to main and use that in a similar way

Re: why is gnulib-tool.sh slow

Collin Funk wrote: > > Wow it is very much faster! \o/ > > That result is interesting. I wonder what part takes the shell script > so long. Simon's oath-toolkit package invokes gnulib-tool 5 times. So, the average run time of each gnulib-tool.sh invocation was 9 sec. Which is not terribly long.

Re: gnulib-tool: Obey environment variable GNULIB_TOOL_IMPL

Simon Josefsson wrote: > OATH Toolkit fails with sh+py though... isn't the --local-dir part > working? It doesn't notice the patches in liboath/gl/override. Indeed. It reads the gl_LOCAL_DIR value from gnulib-cache.m4 but then overwrites it with []. This patch fixes it. 2024-03-15 Bruno

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

Hi Collin, > This patch implements --hardlink and --local-hardlink. Thanks; that's major (and tricky), indeed. > Notice the arguments '-s --hardlink --symlink -h'. I tried to make > sure gnulib-tool.py behaved similarly to gnulib-tool.sh in this case. > > I beleive the correct behavior is to

debugging gnulib-tool.py

Hi, In order to debug Simon's report , I decided to use a GUI debugger, rather than the primitive print(...)-based debugging. * Choice: It seems that PyCharm, VSCode, Spyder, Eclipse with PyDev are the most prominent

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

Collin Funk wrote: > I'm still finishing some things before we can recommend it for > testing. Right. It would not be productive if we had different package maintainers report the same bug(s) at the same time. > But Wget seems like a good project for testing. Do you have > any thoughts Bruno?

Re: gnulib-tool: Obey environment variable GNULIB_TOOL_IMPL

Yesterday I did: > * gnulib-tool: New file, based on gnulib-tool.sh. Here's a small improvement. 2024-03-15 Bruno Haible gnulib-tool: Enhance last patch. * gnulib-tool: If gnulib-tool.sh failed but gnulib-tool.py succeeded, report that and don't erase the

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

Hi Darshit, On 3/14/24 12:12 PM, Darshit Shah wrote: > 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 am enjoying working on it, so hopefully this time will be

Re: gnulib-tool: Obey environment variable GNULIB_TOOL_IMPL

Hi Simon, On 3/15/24 7:30 AM, Simon Josefsson wrote: > Wow it is very much faster! \o/ That result is interesting. I wonder what part takes the shell script so long. Maybe I'll use gnulib-tool as an excuse to expirement with perf, dtrace, etc. > OATH Toolkit fails with sh+py though... Yes,

Re: gnulib-tool: Obey environment variable GNULIB_TOOL_IMPL

Collin Funk writes: >> But in the current state, it fails for nearly every command. There's >> no hope that you can expect identical results from the two implementations >> as long as there are still items in the TODO list. > > Yes. I am working on it. I've added the following lines to my >

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

This patch implements --hardlink and --local-hardlink. It is a larger patch so feel free to ask questions or let me know if I missed anything. Most of the changes are just following the referenced commit. Outside of that, I noticed a bug when testing hard links. After running gnulib-tool.py

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

Collin Funk wrote: > Oops, in the commit before I added some comments directly from > gnulib-tool to main.py as well. Feel free to change them No hurry, no problem. Such comments can stay as they are, in the short term. Bruno