[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: beta-tester call draft
From: |
Bernhard Voelker |
Subject: |
Re: beta-tester call draft |
Date: |
Sat, 20 Apr 2024 15:05:52 +0200 |
User-agent: |
Mozilla Thunderbird |
On 4/20/24 02:22, Bruno Haible wrote:
Hi,
It's now time to call for beta-testers of the Python gnulib-tool.
I plan to post the same text to info-gnu and to planet.gnu.org.
Here is a draft. Please comment!
findutils results ...
---------------------------------------------------------------------
GNU gnulib: calling for beta-testers
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.
$ python3 --version
Python 3.11.8
2. Update your gnulib checkout. (For some packages, it comes as a
git submodule named 'gnulib'.) Like this:
$ git pull
Set the environment variable GNULIB_SRCDIR, pointing to this checkout.
done: gnulib 237cbf1c
3. Set an environment variable that enables checking that the two
implementations behave the same:
$ export GNULIB_TOOL_IMPL=sh+py
done
4. Clean the built files of your package:
$ make -k distclean
Used
$ git clean -xdfq && ./bootstrap && ./configure && && make -k distclean
to get a clean working environment.
5. Regenerate the fetched and generated files of your package.
Depending on the packge, 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>.
How would such a failure look like? Or how should one check?
$ ./bootstrap
no error. :-)
Regarding the timings:
$ export GNULIB_TOOL_IMPL=sh
$ time ./bootstrap
...
real 1m29.778s
ser 1m21.919s
sys 0m19.456s
$ export GNULIB_TOOL_IMPL=py
$ time ./bootstrap
...
real 0m26.536s
user 0m22.881s
sys 0m0.884s
$ time AUTORECONF=true ./bootstrap --skip-po
...
real 0m3.369s
user 0m2.979s
sys 0m0.520s
Cool!
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.
---------------------------------------------------------------------
There will come the question whether there are plans to drop the 'sh' mode,
or if or how long both modes will be maintained in parallel.
Have a nice day,
Berny
- Re: beta-tester call draft, (continued)
Re: beta-tester call draft, Pádraig Brady, 2024/04/20
Re: beta-tester call draft,
Bernhard Voelker <=
- Re: beta-tester call draft, Bruno Haible, 2024/04/20
- Re: beta-tester call draft, Paul Eggert, 2024/04/20
- Re: beta-tester call draft, Bruno Haible, 2024/04/20
- Re: beta-tester call draft, Bernhard Voelker, 2024/04/21
- Re: future Python evolution, Bruno Haible, 2024/04/21
- Re: future Python evolution, Paul Eggert, 2024/04/21
- Re: future Python evolution, Bruno Haible, 2024/04/21
- Re: future Python evolution, Paul Eggert, 2024/04/22
Re: future Python evolution, Bernhard Voelker, 2024/04/21
Re: future Python evolution, Bernhard Voelker, 2024/04/28