Paul Eggert wrote: > I must say that I am starting to reach my limits in debugging this sort > of thing. We have quite a pyramid of hacks here, involving more than > just the usual multilevel combination of make, m4, sh, and sed along > with Git submodules etc.
Yes, these GL_GNULIB_* variables whose name depends on the gnulib-tool invocation require even more attention and care during problem analysis. And when developing patches in this area, things are so complex that I need a written-up plan, because it's impossible to keep the details in memory. > And 'gnulib-tool', 'configure' > and 'make check' are so verrryy slow; to find the commit that caused the > problem, I had to run 'git bisect' overnight because my circa-2005 > Solaris 10 sparc machine is not as fast as modern machines. This is a > long way from my traditional way of developing where I edited a Makefile > and typed 'make' (and that was already too slow!). It's similar on a more modern machine (with GNU grep): time ./bootstrap 99 sec. time ./configure 33 sec. time make 18 sec. time make check 114 sec. ------------------ -------- TOTAL 264 sec. Yes, a build cycle of 4 minutes requires a different kind of developing. In these situations, I typically prepare a script that I can run 100 times, and turn to other things while the script is running. Speeding up 'gnulib-tool' would not help much in this situation. It might reduce the build cycle from 4 minutes to 3 minutes (if it were highly optimized), but that does not change the basic situation. > I don't have a solution to this problem, and to some extent am just venting. It's OK. That's what a mailing list is for :) Bruno
