On 06/26/2012 09:07 PM, Eric Blake wrote: > [adding bug-autoconf, for an autoconf documentation issue] > > On 06/26/2012 11:46 AM, Eric Blake wrote: >> [adding bug-automake, to turn into a formal bug] >> >> On 06/26/2012 11:39 AM, Eric Blake wrote: >> >>> And while looking into how M4 differs from coreutils, I noticed that >>> coreutils uses this via a .m4 file included into its configure.ac: >>> >>> AM_MISSING_PROG(HELP2MAN, help2man) >>> >>> which is roughly supposed to set $(HELP2MAN) to 'path/to/missing [--run] >>> help2man', depending on the version of automake used, without >>> hard-coding it as M4 had done. Maybe M4 could use this trick instead of >>> open-coding its use of 'missing --run', but there's a flaw in that plan >>> - AM_MISSING_PROG is an undocumented macro, and I'm trying hard to keep >>> M4 using only documented interfaces. >>> > > Hmm, autoconf isn't helping matters any; autoconf.texi documents a > hard-coded use of 'missing --run': > > AUTOM4TE = $(SHELL) $(srcdir)/build-aux/missing --run autom4te > > in its section on how to hook in an autotest program into the 'make > check' semantics of automake. > >> >> AM_MISSING_PROG has been around for a while (git log says it was >> introduced in 1997, although the current two-argument version appears to >> date back to commit 9ae48df in Nov 1999), and seems like something >> stable enough to be worth guaranteeing. > > And if we document AM_MISSING_PROG, then autoconf should suggest using it. > Or, given that 'missing' in its current lightweight incarnation has become a more flexible, predictable and probably also more stable tool, it could be moved (together with the definition of the AM_MISSING_PROG macro) to a third-party package (either Autoconf or Gnulib). WDYT?
> Furthermore, it might be nice if automake were smarter about autotest > suites built by autoconf, as the current method for running an autotest > suite is rather verbose in Makefile.am. > Absolutely. Patches welcome ;-) Thanks, Stefano
