On 2025-02-22 10:02, Bruno Haible wrote:
The latest release already contains some multithreading
support already:
That was inadvertent.
When you intersect the resulting list with the gnulib_modules defined in
diffutils/bootstrap.conf, the result is:
exclude
nstrftime
regex
In detail, we have dependency chains
exclude -> regex -> lock -> once -> pthread-once
nstrftime -> localename-unsafe-limited -> getlocalename_l-simple -> lock -> once
-> pthread-once
regex -> lock -> once -> pthread-once
Here, in fact, the dependency chain
localename-unsafe-limited -> getlocalename_l-simple -> lock
can be reduced
Thanks for doing that. I hope that diffutils's existing use of
GNULIB_EXCLUDE_SINGLE_THREAD and GNULIB_REGEX_SINGLE_THREAD are enough
to break the other chains. (Haven't had time to look into it.)
when you --avoid'ed some multithreading modules, no wonder that some
tests fail.
The idea was to --avoid tests that require multithreading. Formerly
diffutils could do that by avoiding only lock-tests; it sounds like it
needs to avoid more now. I plan to look into it.
* Omitting any multithreading code. Users can already force it by configuring
with --disable-threads. As a package maintainer, you can make this the
default by adding this line to configure.ac:
AC_DEFUN([gl_THREADLIB_DEFAULT_NO], [])
Shouldn't this be documented in doc/multithread.texi? At least to
clarify the relationship between it and GNULIB_EXCLUDE_SINGLE_THREAD etc.
Also, since it's checked via m4_ifdef, shouldn't it be defined via
m4_define([gl_THREADLIB_DEFAULT_NO])?
* As long as you
can see (with "ldd") that the package's binaries don't make use of libpthread
and (with "nm | grep ' U '") that the package's binaries don't use
multithreading functions, there is no reason to forcibly remove source files
from the tarball.
It's not simply shrinking the tarball's size. It's making it easier for
diffutils developers and builders to see that multithreading need not be
worried about, so that 'configure' doesn't check for multithreading,
tests don't test for it, etc. Even if from Gnulib's viewpoint it's
simpler to leave the multithreaded source code and tests in, from the
consumer's viewpoint it may well be simpler to omit that stuff when the
package can't significantly benefit from multithreading.
