[Top][All Lists]

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

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

From: Stefano Lattarini
Subject: Re: [PATCH 6/6] aclocal: avoid spurious warnings from autom4te with AC_CONFIG_MACRO_DIRS
Date: Thu, 08 Nov 2012 00:23:19 +0100

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

> 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
  $ echo "define(A,B)dnl" | autom4te - x

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 ;-)


reply via email to

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