Re: [RFC PATCH 0/6] Work around autoconf/automake warnings skew

On 9/22/20 1:04 PM, Zack Weinberg wrote: The main thing I want to discuss before merging these patches is the location of the new Perl function merge_WARNINGS. I put it in ChannelDefs.pm because that is where all the other code relating to WARNINGS is, but it’s only used in autoreconf, so there

Re: [RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

On 9/22/20 3:47 PM, Karl Berry wrote: Zack, the Automake changes look fine to me. Please commit/push at your convenience, as far as I'm concerned. Thanks!! They look good to me, too.

Re: [RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

location of the new Perl function merge_WARNINGS. I defer to your decision, whichever way you think is better, since it doesn't matter to Automake. Subject: [RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side) Zack, the Automake changes look fine to me. Pleas

[RFC PATCH 1/3] New utility function Automake::ChannelDefs::merge_WARNINGS.

This function merges a list of warnings categories into the environment variable WARNINGS, returning a new value to set it to. The intended use is in code of the form { local $ENV{WARNINGS} = merge_WARNINGS ("this", "that"); # run a command here with WARNINGS=this,that,etc } This is not act

[RFC PATCH 3/3] Update documentation of warnings options and strictness levels.

The warning categories ‘cross’ and ‘portability-recursive’ were not mentioned in the manual. Also clarify the relationship between warnings categories and strictness levels, and streamline the description of strictness levels by merging the “Gnits” section into the “Strictness” section. * doc/aut

[RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

This patch set completes the work necessary on automake’s side to bring ChannelDefs.pm back into sync between automake and autoconf. It also updates the documentation of warnings options and arranges to suppress warnings from autom4te --trace in a cleaner fashion. See

[RFC PATCH 2/3] Use WARNINGS=none to suppress warnings from autom4te runs.

aclocal uses autom4te in trace mode to scan configure.ac for macros whose definition is not yet available. It has a kludge to prevent this from producing spurious warnings, but a cleaner, fully backward compatible, way to get the same effect is to set WARNINGS=none in the environment and not pass

[RFC PATCH 3/6] Disable all warnings when running autoconf as a subprocess.

autoheader and autoscan both run autoconf in trace mode, and autoheader makes a point of passing down the warnings options. This means autoheader prints warnings that a regular invocation of autoconf would also print, so in the common case where both are being run by autoreconf, the warnings are du

[RFC PATCH 6/6] Autoupdate AC_{DIAGNOSE, FATAL, OBSOLETE, WARNING} and _AC_COMPUTE_INT.

While working on the previous patches I noticed that all of these macros are officially obsolete, but autoupdate doesn’t replace them. _AC_COMPUTE_INT is easy to autoupdate. AC_{DIAGNOSE,FATAL,WARNING} require a little special handling because their replacements are m4sugar macros, and autoupdate

[RFC PATCH 1/6] Manually sync ChannelDefs.pm from automake.

ChannelDefs.pm *ought* to be kept in sync between automake and autoconf, because it defines the set of valid -W options, and autoreconf assumes that it can pass arbitrary -W options to all of the tools it invokes. However, it isn’t covered by either project’s ‘make fetch’ and it hasn’t actually *be

[RFC PATCH 2/6] New utility function Autom4te::ChannelDefs::merge_WARNINGS.

This function merges a list of warnings categories into the environment variable WARNINGS, returning a new value to set it to. The intended use is in code of the form { local $ENV{WARNINGS} = merge_WARNINGS ("this", "that"); # run a command here with WARNINGS=this,that,etc } This is not use

[RFC PATCH 0/6] Work around autoconf/automake warnings skew

autoreconf runs a bunch of subsidiary tools, and is expected to pass along various command-line settings, such as those controlling warnings. It has historically done this via the command line. However, not all of the tools recognize the same set of command-line warnings options. There’s an exist

[RFC PATCH 5/6] Update documentation related to warnings.

This makes the Texinfo documentation consistent with the previous changes. --help output regarding warnings is already drawn directly from ChannelDefs.pm and thus does not need to be updated. * doc/autoconf.texi: Update all ‘invocation’ sections to describe -W/--warnings consistently, and to re

[RFC PATCH 4/6] Use WARNINGS to pass down warnings options from autoreconf.

autoreconf runs a bunch of subsidiary tools, and is expected to pass along various command-line settings, such as those controlling warnings. It has historically done this via the command line. However, not all of the tools recognize the same set of command-line warnings options. There’s an exist