[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debugging autoconf tests (was: gl_CACHE_VAL_SILENT)

From: Bob Friesenhahn
Subject: Re: debugging autoconf tests (was: gl_CACHE_VAL_SILENT)
Date: Sat, 14 Mar 2020 10:12:31 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

On Sat, 14 Mar 2020, Zack Weinberg wrote:

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

It would be useful if Autoconf/Automake provided a standard way for an uninformed user to be able to provide a minimal tarball or report which includes essential information for a maintainer to be able to understand the issue and provide assistance. The current paradigm assumes that the uninformed user is going to have enough understanding that they would be able to find and study artifacts like config.log or a test suite report and take corrective action.

Configure is very easy to use until things go wrong.

Some behavior of Autotools is very confusing for users. In particular, it is pretty common for generated files to be provided to users (e.g. in a tarball, or via git) and then the auto-maintaining features of Autotools fail because they are unable to find the specific version of aclocal, etc., required to assure that the build files are up to date. Sometimes the build files are fine but the time stamps are wrong due to how the source control system works. This causes users to become afraid of Autotools.

Anything which encourages users to not be afraid to build from source code (rather than depending on binary packages built by others) is useful to the future of free software.

Bob Friesenhahn
GraphicsMagick Maintainer,
Public Key,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]