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
