Re: [PATCH 6/6] aclocal: avoid spurious warnings from autom4te with AC_CONFIG_MACRO_DIRS

[Stefano Lattarini]

Hi Eric, sorry for the delay.

On 11/07/2012 09:33 PM, Eric Blake wrote:
> On 11/07/2012 01:08 PM, Nick Bowler wrote:
>>
>> I really think this test needs to be done at runtime.  Two reasons:
>>
>>   (1) A user may first ugprade Automake, then upgrade Autoconf.  They
>>       will then get the spurious warnings even though they have
>>       sufficiently recent versions of both Automake and Autoconf.
>>
> 
> Good argument.  Also, a user may first upgrade autoconf and then
> automake.  We want to make sure both upgrade paths are sane, if
> possible, rather than requiring a lockstep upgrade.
> 
>>   (2) A user may have more than one version of Autoconf installed, one
>>       without the warning category and one with.  The value hardcoded
>>       into aclocal at build time is therefore guaranteed to be wrong
>>       for at least one installed version.
>>
>> Furthermore, the test itself can be simplified: Just run autom4te
>> -Werror -Wwhatever on empty input (/dev/null will work).  For example:
>>
>>   autom4te -Werror -Wno-m4require-without-m4defun /dev/null
> 
> Hmm, this goes back to my question of whether autoconf should expose the
> ability to silence the message by means of including an extra file which
> does an m4_define, rather than via a new -W command-line argument.
>
Given the complications and ugliness stemming from my approach (thanks
to Nick for pointing them out in time), I agree this is probably a better
idea.

> Allowing file inclusion as the witness of whether to warn would work
> even for older autoconf (where including the file has no effect), rather
> than the current situation of warning about an unknown option.
>
Good thinking.  And since aclocal is not expected to read any input from
stdin anyway, such macro definition could be passed directly from the
command line, as in:

  $ cat x
  A
  $ echo "define(A,B)dnl" | autom4te - x
  B

saving us from the need to handle temporary files.

So, should I attempt a patch along this new directions, or are you going
to post one yourself? (In which case I'll save myself some time and avoid
duplicate efforts, especially considering that a patch from you will
certainly be better then mine ;-)

Thanks,
  Stefano