bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib-tool.py consider automake_subdir=false support


From: Mitch Capper
Subject: Re: gnulib-tool.py consider automake_subdir=false support
Date: Sat, 3 Jun 2023 04:37:02 -0700


> It's nice that you consider enhancing gnulib-tool.py. But don't underestimate
the task:

Yes, this suggestion was _only_ to support situations where no automake-subdir was required and we stripped the path.    I have automated several build packages so could likely automate testing of the gnulib-tool.py vs gnulib-tool on them both and seeing the differences.   Is there a set of packages normally tested against?  Right now with the manual sed hack I am using it successfully with tar, patch, gzip, findutils, bash.  The other patches I mention are targeting the greater gnulib library rather than gnulib-tool.py specifically (as for many packages it has been working just great).

> > I have been very grateful for gnulib-tool.py as it results in some massive
> > bootstrap speed improvements (over 10x) on Windows.

>In which environment did you make these measurements? Cygwin? MSYS2? WSL?

MSYS2.  I have WSL and plenty of linux machines but my current side project is native MSYS2 MSVC/cl.exe compiling.  Honestly the 10x was conservative.  With AV off, on a fairly quality SSD drive running bootstrap on tar (with a good number of gnulib modules) the speed is:

time /WIN64LinuxBuild/build/f_tar_build.sh
./bootstrap: gnulib/gnulib-tool.py      --no-changelog     --aux-dir=build-aux     --doc-base=doc     --lib=libgnu     --m4-base=m4/     --source-base=gnu/     --tests-base=tests     --local-dir=gl      --without-tests --symlink     --import ...

real    0m35.359s
user    0m4.792s
sys     0m18.634s

vs shell bootstrapper:
real    17m40.540s
user    3m18.828s
sys     8m44.022s

Which is a good 30x speedup.

I will also note that it is running the python version and then running the shell version with no actual module changes.  I would assume that to be one of the fastest bootstrapping options.

Obviously WSL with native forking will destroy windows process creation any day, and dealing with it isn't an issue.  When you have dozens of processes being created and destroyed every few seconds https://imgur.com/a/M96S72J it is easy to get the why. I am just mentioning how nice the tool has been when I can use it for packages.  As I sometimes was running the bootstrap process a few dozen times a day it would be the difference between waiting and tabbing away to do something else:)

~Mitch (they/them)

reply via email to

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