* Bruno Haible wrote on Mon, Sep 18, 2006 at 05:20:14PM CEST: > > > I think it may be possible to shave off another good part, but the next > > changes probably have a higher source code change to improvement ratio > > (caching func_lookup_file results could help; or rewriting func_get_* > > to work on lists of modules; both seem like not too high hanging fruit). > > Uhh, I would be a bit reluctant to apply the second type of changes, since > it changes the program structure for no other reason than speed. The major > bottleneck at this time are the autom4te / m4 invocations after gnulib-tool.
Not necessarily. Some gnulib-using packages have actually pretty small configuries (beside Eric's argument). (IMHO there's no reason to discuss this until there is something to discuss; I don't have a patch yet.) > (I'm turning off autom4te's caching in my ~/.autom4te.cfg since temporary > directories would be acceptable for me in /tmp, but not in the middle > of my source code directories.) I know, Stepan and Alexandre have mentioned that. ;-) Apparently you do not read the automake-patches list (not that I expect you to, not at all), but Alexandre once mentioned that autom4te could be configured to have a global cache directory: http://lists.gnu.org/archive/html/automake-patches/2006-05/msg00031.html for example like this: cat >$HOME/.autom4te.cfg <<EOF begin-language: "Autoconf-without-aclocal-m4" args: --cache=/tmp/my-autom4te.cache end-language: "Autoconf-without-aclocal-m4" EOF Be warned (see above link) to not build several _different_ packages in parallel; in that case you should use a per-package cache (e.g., by writing a suitable configuration in package/.autom4te.cfg). I'm sure the bug-autoconf list will enjoy reading and fixing any bugs that this exposes. ;-) Cheers, Ralf
