If you are developer on a package that uses GNU gnulib as part of its build system:
gnulib-tool has been known for being slow for many years. We have listened to your complaints. A rewrite of gnulib-tool in another programming language (Python) is ready for beta-testing. It is between 8 times and 100 times faster than the original gnulib-tool.
Both implementations should behave identically, that is, produce the same generated files and the same output. You can help us ensure this, through the following steps:
1. Make sure you have Python (version 3.7 or newer) installed on your machine.
2. Update your gnulib checkout. (For some packages, it comes as a git submodule named 'gnulib'.) Like this:
$ git checkout master
$ git pull
Set the environment variable GNULIB_SRCDIR, pointing to this checkout.
If the package is using a git submodule named 'gnulib', it is also advisable to do
$ git commit -m 'build: Update gnulib submodule to latest.' gnulib
(as a preparation for step 5, because the --no-git option does not work as expected in all variants of 'bootstrap').
3. Set an environment variable that enables checking that the two implementations behave the same:
$ export GNULIB_TOOL_IMPL=sh+py
4. Clean the built files of your package:
$ make -k distclean
5. Regenerate the fetched and generated files of your package. Depending on the package, this may be a command such as
$ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
or
$ export GNULIB_SRCDIR; ./autopull.sh; ./autogen.sh
or, if no such script is available:
$ $GNULIB_SRCDIR/gnulib-tool --update
If there is a failure, due to differences between the 'sh' and 'py' results, please report it to bug-gnulib@gnu.org.
6. If this invocation was successful, you can trust the rewritten gnulib-tool and use it from now on, by setting the environment variable
$ export GNULIB_TOOL_IMPL=py
7. Continue with
$ ./configure
$ make
as usual.
And enjoy the speed! The rewritten gnulib-tool was implemented by Dmitry Selyutin, Collin Funk, and me.
#gnu #gnuorg #opensource
