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.]

Reply via email to