Re: debugging autoconf tests (was: gl_CACHE_VAL_SILENT)

[Zack Weinberg]

On Fri, Mar 13, 2020 at 10:49 PM Bruno Haible <address@hidden> wrote:
>> but when something goes
> > wrong, the poor schmuck who has to debug it wants to know that it was
> > the test for `ceil` (for instance) that hung the build, not the
> > unrelated thing that happens to have been tested right before that.
>
> Hanging autoconf tests are rare. And even in that case, looking at
> the configure output does not help much, because it won't tell you
> whether the compiler is taking hours or whether the test program hangs.
> In practice, when something hangs, "ps aux" or "pstree -p" (when available)
> is a better starting point for debugging.

Aha, you're coming at this from the perspective of debugging with
interactive access to the system where the problem happens.

All of the worst autoconf-related bugs I've had to deal with in the
past decade or so, showed up in CI environments that I did _not_ have
interactive access to.  I only got the transcript of the build.  I had
to specifically add code to dump the contents of config.log, and then
track things down further by adding extra AC_MSG_* within the problem
macro.  You can probably imagine how frustrating this can be,
especially when the cycle time is a half-hour or more.  I haven't had
to deal with any of these problems with a project that made heavy use
of gnulib, but I would have been quite annoyed to find that I was
barking up the wrong tree because configure didn't tell me that it was
doing some check because it didn't seem important enough.

Also, overriding $as_echo(_n), and your suggestion to override
AS_ECHO_N with pushdef, are more problematic than you may realize
because they affect what gets written to config.log, not just what
gets written to configure's stderr.  (Because configure writes to
config.log with a construct like AS_ECHO([...]) >&AS_MESSAGE_LOG_FD.)

May I suggest that what you really want is a --quiet switch for
configure, a la V=0 with automake-generated makefiles?  If you had
that, would you be OK with changing all of the gnulib .m4 files that
currently use gl_AC_CACHE_VAL_SILENT to use AC_CACHE_CHECK instead?

zw