automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#11793: AM_MISSING_PROG undocumented


From: Stefano Lattarini
Subject: Re: bug#11793: AM_MISSING_PROG undocumented
Date: Wed, 27 Jun 2012 00:56:04 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]