Re: [PATCH] gnulib-tool.py: Fix function call on incorrect object.
On 2/19/24 1:36 PM, Bruno Haible wrote: > You don't need to go to the './configure' and 'make' stages at this point. > Just ensuring that the outputs of gnulib-tool and gnulib-tool.py are the > same will sufficiently guide you. Ah, I see. Thanks for this and the rest of the advice. Collin
Re: [PATCH] gnulib-tool.py: Fix function call on incorrect object.
Collin Funk wrote: > > 65% of the .py code has been verified to be in sync with the bash code; > > 35% still to go. And then, the changes from the gnulib-tool.py.TODO list > > I see. I had it open and compared some of it to the shell script and it > wasn't too hard to follow. Maybe I could help hack away at some of in my > free time. If you want to do help with gnulib-tool.py, I would suggest not to continue directly with the comparison / review (because it's hard to keep track of what has been reviewed / tested and what has not), but rather work across the gnulib-tool.py.TODO file, from the bottom to the top. > I assume the best way to test it would be to create a small test > directory with a few modules? The best way to test it is to take a specific source package that uses a number of modules (I used wget2, but you can use coreutils or any other package), run gnulib-tool and gnulib-tool.py with identical command-line options, and compare/verify the results on either side. > I think all of the header file > replacements would break the build so whichever ones avoid using those. You don't need to go to the './configure' and 'make' stages at this point. Just ensuring that the outputs of gnulib-tool and gnulib-tool.py are the same will sufficiently guide you. Bruno
Re: [PATCH] gnulib-tool.py: Fix function call on incorrect object.
Bruno Haible writes: > The status: It's about 2/3 complete. 4 months of work have gone into it, > and 2 months of work still remaining. (That's my estimation, based on > two weeks of work that I put in, in 2022.) > 65% of the .py code has been verified to be in sync with the bash code; > 35% still to go. And then, the changes from the gnulib-tool.py.TODO list I see. I had it open and compared some of it to the shell script and it wasn't too hard to follow. Maybe I could help hack away at some of in my free time. I assume the best way to test it would be to create a small test directory with a few modules? I think all of the header file replacements would break the build so whichever ones avoid using those.
Re: [PATCH] gnulib-tool.py: Fix function call on incorrect object.
Bruno Haible writes: >> What is the status of the Python gnulib tool? I'm not sure how far >> behind it is compared to the shell script but it seems like it would >> be much faster. I would say more maintainable but I might just be bad >> at writing shell scripts. :) > > Yes, it's the hope that it will be faster that is the main motivation > behind the Python rewrite. Orthogonal to a rewrite in python: is it possible to design a reliable caching mechanism? Something similar to CONFIG_SITE for autoconf? I find that ./gnulib-tool takes a long time and 95% of the time I use it, it ended up doing exactly the same thing as it did last time I ran it: copying a set of possibly patched files out of the gnulib directory. How about logic like this: . $GNULIB_SITE if test -d $gnulib_cache_dir; then rsync -av $gnulib_cache_dir . else if test -n "$gnulib_cache_dir"; then mkdir $savedir rsync -av . $savedir # do whatever gnulib normally is doing # compare . with $savedir, saving a copy of each modified # file into $gnulib_cache_dir fi then I could put something like this into a $GNULIB_SITE script: if test -z "$gnulib_cache_dir"; then hash=`echo $PWD|md5sum|cut -d' ' -f1` my_cache_dir=$HOME/.cache/gnulib.site gnulib_cache_dir=$my_cache_dir/cache.`basename $PWD`.$hash test -d $gnulib_cache_dir || mkdir -p $gnulib_cache_dir fi /Simon signature.asc Description: PGP signature
Re: [PATCH] gnulib-tool.py: Fix function call on incorrect object.
Hi Collin, > GNU m4 gave the following error: > > bootstrap: running: gnulib/gnulib-tool.py --no-changelog --no-libtool > --symlink --update > Traceback (most recent call last): > File "/home/collin/.local/src/m4/gnulib/gnulib-tool.py", line 1171, in > > main() > File "/home/collin/.local/src/m4/gnulib/gnulib-tool.py", line 886, in main > importer = classes.GLImport(config, mode) >^^ > File "/home/collin/.local/src/m4/gnulib/pygnulib/GLImport.py", line 243, in > __init__ > if self.checkInclTestCategory(TESTS['tests']) and self.config['conddeps']: >^^ > AttributeError: 'GLImport' object has no attribute 'checkInclTestCategory' > > I assume this was just caused by a small coding typo (if that is a > thing). This patch should fix it. Thanks! Applied. > What is the status of the Python gnulib tool? I'm not sure how far > behind it is compared to the shell script but it seems like it would > be much faster. I would say more maintainable but I might just be bad > at writing shell scripts. :) Yes, it's the hope that it will be faster that is the main motivation behind the Python rewrite. The status: It's about 2/3 complete. 4 months of work have gone into it, and 2 months of work still remaining. (That's my estimation, based on two weeks of work that I put in, in 2022.) 65% of the .py code has been verified to be in sync with the bash code; 35% still to go. And then, the changes from the gnulib-tool.py.TODO list need to me implemented on the Python side. Then would come a phase of public testing... Bruno
