Re: general comments about gnulib

[Bruno Haible]

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