Paul Eggert wrote: > > 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.
These flags don't break dependency chains at the module level. They optimize the code, despite of the dependencies. > > * 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. I'm OK to document it, once you have made sure that it works as intended :) Because it has not been sensibly tested so far. > Also, since it's checked via m4_ifdef, shouldn't it be defined via > m4_define([gl_THREADLIB_DEFAULT_NO])? Since an AC_DEFUN results in an m4-level definition, either AC_DEFUN or m4_define would likely work. In the documentation, I would prefer AC_DEFUN, since m4_define is more "exotic" for most configure.ac maintainers. > 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 Such a statement is important, yes: The omnipresent use of global and 'static' variables is only possible when multithreading is not an issue. But isn't the best way to formulate this statement a sentence in the HACKING file? > 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. Maybe the easiest way to bridge the two viewpoints is that, at the end of running 'bootstrap', you have a command that removes selected files from the lib/ directory? The bootstrap_post_import_hook and bootstrap_epilogue functions are good candidates, IMO. Bruno
