On 2021-10-01 15:37, Yaakov Selkowitz via Cygwin-apps wrote:
On Wed, 2021-09-29 at 22:15 -0600, Brian Inglis wrote:
Autotools needs m4 macros in autoreconf-archive to config for gcov and
other dependencies or build fails with e.g.
"configure.ac:33: error: possibly undefined macro: AX_CODE_COVERAGE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation."
CI scallywag setup does not install nor does cygport nor autoconf
require autoconf-archive so packages have to include in BUILD_REQUIRES.
As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that
would be the more appropriate place for an autoconf-archive requirement,
otherwise cygport would have to require it, which is not so obvious.
autoconf-archive would be a build requirement of the package whose
configure.ac references the AX_* macro, not of the autotools themselves.
It appears to be just installed as part of build or development packages
on upstreams systems, perhaps the GNU Build System, such that they don't
even mention it as a requirement.
It appears that the newer AX_... macros are defined in autoconf-archive,
and they are now being used in packages.
I would prefer it be required by autoconf or cygport, as I expect more
if its macros will be used in the future, especially as more packages
will require it to build with autotools, but it is not obvious that part
of the autoconf infrastructure is not automatically installed, nor where
one should look to find AX_... whatever in a package that is not installed.
I only figured it out because I was looking for issues with autotools
macros because of issues with gnulib in GNU packages, which I have been
dealing with recently in three packages, and expect more unless they
pull in the newer release with the patch applied.
I have posted a general message to the list to watch out for that issue,
which crashes all programs configured with it.
As the lack of autoconf-archive installed by scallywag CI kills jobs run
when commits are pushed, I expect this to cause some frustration to
maintainers, which given lag in package updates with the current
shortage of people and time, I would like to mitigate likely future
common issues as much as possible.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]