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
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
