Re: fix: autoreconf fails due to .m4 files added but not installed

Mike Frysinger <[email protected]> Sat, 13 Jan 2024 00:02:38 -0500

Newsgroups	gmane.comp.sysutils.automake.general
Message-ID	<ZaIZboxDOkEsfwyd@vapier>

On 28 May 2022 12:14, Jim Meyering wrote:
> A few days ago I was preparing to release grep and wanted to make sure
> it'd work with the latest automake and autoconf, so I built and installed
> each from master. That exposed these errors when bootstrapping grep. I
> think it was a prerequisite to have run grep's "make maintainer-clean":
> 
>   configure.ac:41: warning: _AM_PROG_RM_F is m4_require'd but not\
>     m4_defun'd
>   configure.ac:41: warning: _AM_PROG_XARGS_N is m4_require'd but not\
>     m4_defun'd
>   configure:5058: error: possibly undefined macro: _AM_PROG_RM_F
>   configure:5059: error: possibly undefined macro: _AM_PROG_XARGS_N
> 
> I've just pushed the attached fix.
> Introduced in v1.16.5-46-g38da1d906 and v1.16.5-45-g3099097d7
> so this doesn't need a NEWS update.
> 
> Mike, can you add an automake test that would have caught this?

does `make distcheck` not catch this ?  would be nice if we could catch
with a git checkout directly, but seems difficult to pull off.

would it be reasonable to assume that every m4/*.m4 file is supposed
to be installed ?  that wouldn't be too hard to run tests against,
but it would make things a little more tricky for devs working out
of the git tree with uncommitted local changes.

the problem with running $ACLOCAL is that it's configured to search
the local ../m4/ tree for all macros that exist ...

is there some m4 invocation we could run that would scan all the
installed m4 files ?  we can pass down the known list of m4 files to
be installed, but how to actually scan/validate them i'm not sure.
-mike

signature.asc (application/pgp-signature, 833 B)