bug-gnulib
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]