Inspired by Collin Funk’s suggestion in:
https://lists.gnu.org/r/autoconf-patches/2024-06/msg00000.html
* bin/autom4te.in (handle_output):
* bin/autoscan.in, bin/ifnames.in (scan_c_file):
Also recognize #elifdef and #elifndef.
* tests/tools.at (ifnames): Test it for ifnames.
Simplified version of a suggestion by Reuben Thomas in:
https://lists.gnu.org/r/bug-autoconf/2024-04/msg00021.html
* bin/autom4te.in (warn_forbidden): Change message wording.
* tests/tools.at (autom4te and whitespace in file names)
(forbidden tokens, exceptions): Adjust tests to match new behavior.
Today it came to my attention that, if you don’t already know that all
the GNU manuals are readable in HTML format on gnu.org, it’s not easy
to find one starting from typical --help output and/or help2man-
generated manpages. Let’s do a little to make this easier, and have
“https://www.gnu.org/software/autoconf/manual/” appear prominently in
both the --help output and the trailer text of our generated manpages.
This uses the extended tmac.an “.MT” and “.UR” directives, which are
not universal, but I suspect anyone who’s actively using Autoconf on
an old system does not need the advice, and they can get it from
--help regardless.
* bin/autoconf.in, bin/autoheader.in, bin/autom4te.in, bin/autoreconf.in
* bin/autoscan.in, bin/autoupdate.in, bin/ifnames.in:
Refer specifically to https://www.gnu.org/software/autoconf/manual/
for the web version of the complete Autoconf manual.
* man/common.x: Likewise; also, suggest the Savannah tracker as
well as bug-autoconf for bug reports.
m4_warn([category], [message]) passes its arguments directly to
Autom4te::Channels::msg. If the category argument is not a recognized
“channel”, that function will crash and emit a *Perl* stack trace,
which makes it look like there’s something wrong with autoconf or
autom4te, rather than something wrong with the script.
Making matters worse, in autoconf 2.69, the manual said you could
use “all” and the empty string as the first argument to m4_warn.
As far as I can tell, neither of those was ever a valid message
channel, and the manual was corrected in 2.70, but we still got
a bug report from someone who tried it.
This patch makes us issue a nice helpful user error, instead of a
confusing internal error, when Autom4te::Channels::msg is called with
a bogus channel argument. If the bogus channel is “all” or the empty
string, that error is demoted to a -Wobsolete warning. If it is one
of the other special tokens recognized by -W, we customize the error
message, since someone might’ve thought that “none” being acceptable
to -W meant it was also acceptable to m4_warn. The --help output for
autoconf, autoheader, autom4te, and autoreconf is also adjusted to
clarify that not all of the tokens recognized by -W count as
warning categories.
(Oddly enough, the lack of filtration at the autom4te level means
m4_warn([error], […]) actually does issue an error. There’s no other
way to get exactly that effect — m4_errprintn(…) and m4_fatal(…)
both do something a little different — so I I propose to leave that
alone for now and promote it to a proper, documented feature, probably
spelled m4_error(…), post-2.72.)
Channels.pm and ChannelDefs.pm are shared with Automake. I believe
there is nothing you can write in a Makefile.am that will cause
Automake::Channels::msg to be called with an arbitrary user-supplied
channel argument, so these changes should have no visible effect on
that side of the fence.
Addresses <https://savannah.gnu.org/support/?110872>.
* lib/Autom4te/Channels.pm (msg): If the channel argument is invalid,
don’t crash; report the mistake and use the ‘syntax’ channel.
(report_bad_channel): New function for reporting invalid channels.
* lib/Autom4te/ChannelDefs.pm (usage): Clarify that the list of
warning categories is exhaustive, and that “all”, “none”,
“no-CATEGORY”, and “error” are not warning categories.
* bin/autoconf.in, bin/autoheader.in, bin/autom4te.in,
bin/autoreconf.in: Tweak --help text.
* tests/m4sugar.at (m4@&t@_warn (bad categories)): New test.
The Automake test suite wants this in order to know if it’s safe to
reduce the length of various delays for the purpose of ensuring files
in autom4te.cache are newer than the corresponding source files. We
can also take advantage of this to speed up a couple of tests in our
own testsuite.
* lib/Autom4te/FileUtils.pm: Provide (but do not export) a flag
$subsecond_mtime, indicating whether the ‘mtime’ function reports
modification time with precision greater than one second.
Reorganize commentary and import logic for clarity. Add
configuration for emacs’ perl-mode to the bottom of the file.
* bin/autom4te.in ($version): If $Autom4te::FileUtils::subsecond_mtime
is true, print “Features: subsecond-mtime” as the second line
of --version output.
* lib/autotest/general.m4: Move definitions of AS_MESSAGE_LOG_FD,
AT_JOB_FIFO_IN_FD, and AT_JOB_FIFO_OUT_FD to top level and change
the latter two to be defined using _AT_DEFINE_INIT. This enables
use of AS_MESSAGE_LOG_FD in AT_TESTS_PREPARE code.
* tests/local.at (AT_MTIME_DELAY): New utility that delays a test for
an appropriate time to ensure all files created before its use are
considered older than all files created afterward. The delay will
be as short as possible.
(AT_TESTS_PREPARE): Calculate and log the delay used by AT_MTIME_DELAY.
Only use a delay shorter than one second if the build filesystem,
our autom4te, and the automake on the PATH all support this.
(AT_CMP): En passant removal of unnecessary blank lines.
* tests/tools.at: Use AT_MTIME_DELAY, instead of sleeping for a
hardcoded interval, everywhere the delay was to control file
timestamps.
On OS/2, chmod(2) cannot be applied to an open file.
Instead set the desired permissions when the file is initially
created, using the PERMS argument to File::Temp::tempfile if
possible, or by manually emulating that feature if the system
perl does not provide a new enough version of File::Temp.
This has the nice side effect that we no longer need to handle
the umask manually.
* autom4te.in (tempfile_with_mode): New function.
(handle_output): Use tempfile_with_mode instead of directly using
File::Temp plus chmod.
Co-authored-by: KO Myung-Hun <komh78@gmail.com>
Problem reported by Bogdan via Jacob Bachmeyer in:
https://lists.gnu.org/r/autoconf/2023-04/msg00002.html
* bin/autom4te.in: If a file timestamp equals a dependency’s
timestamp, consider the file to be out of date. Although this may
result in extra work, it fixes some rare timing bugs.
Of all the installed programs (autoconf, autoheader, autom4te,
autoreconf, autoscan, autoupdate, ifnames) autoconf is the only one
that is a shell script instead of a Perl script. This means it has to
do a lot of fiddly quoting and requoting to assemble an autom4te
command line, it doesn’t get to use the shared option handling code in
Autom4te/{General,Getopt}.pm, and it has to duplicate usage text that
properly should only be in Autom4te/ChannelDefs.pm. It also means
there’s extra code in build-aux/help-extract.pl just for it, and a
special two-phase generation process in bin/local.mk.
This also paves the way for the bootstrap script mentioned in the
previous commit; it will only have to know how to deal with
substitution variables, not generation of m4sh scripts.
The new script winds up being slightly longer on disk but that’s
because our boilerplate for Perl scripts is quite long. The code is
visibly simpler.
* bin/autoconf.as: Rename to bin/autoconf.in and rewrite in Perl.
* bin/local.mk (EXTRA_DIST): Change autoconf.as to autoconf.in.
(MOSTLYCLEANFILES): Don’t delete autoconf.in.
(bin/autoconf.in): Delete rule.
(ETAGS_PERL): Add autoconf.in and sort list.
(ETAGS_SH): Delete, no longer needed.
* tests/tools.at: Syntax-check autoconf as a Perl script.
* build-aux/help-extract.pl: Remove all code for extracting usage text
from shell scripts.
* man/autoconf.w, man/local.mk: Refer to autoconf.in, not autoconf.as.
Autoconf’s diagnostics now follow current GNU coding standards,
which say that diagnostics in the C locale should quote 'like this'
with plain apostrophes instead of the older GNU style `like this'
with grave accent and apostrophe.
Some projects intentionally don't call AM_GNU_GETTEXT_(REQUIRE_)VERSION
because they have all of the gettext infrastructure checked into version
control and they want autoreconf to _not_ run autopoint. Therefore, make
the “AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_(REQUIRE_)VERSION”
and “AM_GNU_GETTEXT_(REQUIRE_)VERSION is used, but not AM_GNU_GETTEXT”
diagnostics be warnings again, as they were in 2.69.
(Technically these diagnostics were always errors, in the sense that
they were reported with a call to Autom4te::Channels::error(), but
prior to 2.70, error() calls made by autoreconf did not cause
autoreconf to exit unsuccessfully, due to an unrelated bug. So people
came to depend on these diagnostics not being fatal.)
Automake generates a Makefile rule for regenerating the configure
script, that relies on an invocation of ‘autoconf’ always bumping the
timestamp on the configure script, even if it hasn’t changed.
The patch to make autom4te update the output file atomically
(1725c94714) broke this.
Fixes several failures in automake’s test suite.
* bin/autom4te.in (handle_output): Always call update_file with force=1.
* tests/tools.at (autoconf: timestamp changes): New test.
While testing something else, I noticed that autom4te may print a
nonsensical error message when it fails to create autom4te.cache,
because it checks again whether the directory already exists before
giving up, and this clobbers errno.
Instead of doing (the perl equivalent of)
test -d $cache || mkdir $cache || test -d $cache
call mkdir unconditionally. If it fails with an errno code other than
EEXIST, consider that a hard failure; if it fails with EEXIST, check
whether the thing that exists is in fact a directory. (A symlink to
a directory qualifies; I wouldn’t be surprised if people are moving
autom4te.cache around with symlinks.)
Either way, if we fail, report strerror(errno) from the original
mkdir failure. Also, print the current working directory as part
of the error message; this aids debugging when you’re working with a
big hairy nested tree.
* bin/autom4te.in: Don’t check whether autom4te.cache exists before
attempting to create it. Only stat autom4te.cache if mkdir fails
with EEXIST, otherwise fail immediately. Make sure to report the
errno code from mkdir, not the subsequent stat (if any). Report
the current working directory as part of the error message.
* tests/tools.at: Verify that autom4te reports the actual reason when
it fails to create autom4te.cache. Verify that failure to create
autom4te.cache because that name exists, but isn’t a directory,
is detected.
Old versions of install-sh did not have a timestamp line. Therefore,
treat the absence of a timestamp line as indicating a very old file
(that --install --force should replace), not as an error.
Problem reported by Pascal Terjan.
* bin/autoreconf.in (extract_time_stamp): Return 1970-01-01 when
no timestamp line is found.
* tests/torture.at (Missing auxiliary files (--force)):
Test replacement of old install-sh with no timestamp line.
In testing on Darwin (OSX), sometimes warnings reported from M4 code
reach autom4te with no stack trace at all, causing the perl script to
crash with a “use of uninitialized value” error. The root cause of
the problem is not clear to me, but the script certainly shouldn’t
crash.
Problem found by Jannick <thirdedition@gmx.net>.
* bin/autom4te.in: When processing warnings, make sure $stacktrace is
defined.
The new feature of autoreconf --install installing config.guess,
config.sub, and install-sh itself didn’t implement --force mode
correctly; existing files would not be overwritten.
The fix has two parts. If --force is in effect, we try to install
everything that we can from the needed-auxfiles list *before* checking
which of them already exist. But also, we don’t overwrite existing
files unconditionally, even with --force; we only do so if the file we
can install has a newer “timestamp” line than the copy at the
destination. This is because Automake can also install all of the
files we can install. Suppose someone is using autoconf 2.70 with a
newly released automake 1.17; automake 1.17 will presumably ship with
a newer config.guess than autoconf 2.70 did; that version should win.
Fixes bug #110371.
* bin/autoreconf.in (extract_time_stamp, our_aux_file_is_newer): New functions.
(install_aux_file): If the destination exists, and our copy is not
newer, do not overwrite it.
(autoreconf_current_directory): When $force is true, attempt to
install all needed aux files *before* scanning for missing aux files.
(throughout): Remove extra \n from various error messages.
* tests/torture.at (Missing auxiliary files (--force)): New test.
Despite what the documentation says, ‘new File::Temp’ does not work
reliably in perl 5.6.x. Rather than figure out exactly what is wrong
with it, let’s just stick to ‘tempfile’.
* bin/autom4te.in (handle_output): Use tempfile function instead of
object-oriented File::Temp interface.
* bin/autoreconf.in (install_aux_file): Likewise.
In 2003, Joey Hess reported the following bug against Debian's
autoconf package (see http://bugs.debian.org/221483):
I noticed that if I ctrl-c autoconf, it can leave a partially
written, executable configure script. I was lucky enough to
get a configure script that exited with a shell parse error,
but if I had been unlucky, it might have exited 0 without
doing all the tests I expected it to do. That would have
sucked to ship to users.
There are many ways to update a file in a way that is not
prone to these problems, and I suggest that autoconf adopt
one of them.
Ben Pfaff wrote a patch to make autom4te replace the output file
atomically; Debian has carried it since 2006. He submitted it
to autoconf upstream in 2008 but it never went anywhere.
I (Zack) have dusted off the patch and made some minor improvements:
using File::Temp (with DIR set to the directory of the output file)
instead of a predictable temporary file name, and using
Autom4te::FileUtils::update_file instead of File::Copy::move.
I do not attempt to test the fix (the test would be inherently racey)
nor do I have autom4te delete the temp file if it crashes while the
file is being written (there is no way to do this with 100%
reliability and it strikes me as likely to cause more problems than it
solves).
Fixes our bug #110305.
* bin/autom4te.in (handle_output): When $output is to a regular or
nonexistent file, write to a temporary file in the same directory
and then rename it over $output after completion.
As reported in https://github.com/gentoo/gentoo/pull/163, gettext 0.19.6
supports using AM_GNU_GETTEXT_REQUIRE_VERSION (specifying a *minimum*
required version of gettext) instead of AM_GNU_GETTEXT_VERSION
(which specifies a *fixed* required version of gettext).
Update autoreconf to support both.
* bin/autoreconf.in (autoreconf_current_directory): Check for
AM_GNU_GETTEXT_REQUIRE_VERSION as well as AM_GNU_GETTEXT_VERSION.
Update diagnostics about using AM_GNU_GETTEXT_VERSION but not
AM_GNU_GETTEXT, or vice versa, to match.
* doc/autoconf.texi (autoreconf Invocation): Update to match.
In very old perls (I noticed this with 5.8.4), File::Temp objects are
not automatically stringified in all contexts where we expect them to
be, causing autoreconf to crash.
* bin/autoreconf.in (install_aux_file): Explicitly extract the
temporary file’s name from $temp, and use that in all the places we
were using $temp.
Make ‘autoreconf --install’ add config.sub, config.guess, and
install-sh to the source tree when necessary. This is only relevant
for packages that don’t use Automake, because ‘automake --add-missing’
already adds these scripts to the source tree, but apparently there
are plenty of packages out there that don’t use Automake, didn’t need
config.{sub,guess} with autoconf 2.69, and do need them with 2.70.
Such packages will need to have their equivalent of ‘make dist’
manually updated to ship the new files, of course.
This patch also has ‘autoreconf’ issue an error if aux files are
missing and ‘--install’ *wasn’t* used, or if --install *was* used but
could not install all the missing files. This error is more likely to
be caught by maintainers than the configure-time error added in the
previous patch. It is not currently practical to make autoconf itself
issue this error message, because of how the autoconf wrapper script
is different from all the other wrapper scripts. Also, autoreconf
runs automake *after* autoconf, so we’d get spurious errors from
packages that do use automake.
* bin/autoreconf.in ($buildauxdir): New package global, initialized
to $pkgdatadir/build-aux, or to $ENV{autom4te_buildauxdir} if that’s set.
(find_missing_aux_files, can_install_aux_files, try_install_aux_files)
(install_aux_file, make_executable): New subs.
(autoreconf_current_directory): Trace AC_REQUIRE_AUX_FILE.
After running all tools that might install aux files, try to
install aux files ourself if --install was given.
After that, report on any that are still missing.
* lib/autom4te.in (Autoreconf-preselections): Add AC_REQUIRE_AUX_FILE.
Make list order consistent with list order in autoreconf.in.
* tests/wrapper.as: Set autom4te_buildauxdir to point to location of
config.guess, config.sub, and install-sh within the source tree.
* lib/local.mk: Install config.guess, config.sub, and install-sh
into $(pkgdatadir)/build-aux.
* doc/autoconf.texi: Document that autoreconf can now install
config.guess, config.sub, and install-sh itself without help from
automake, but packages not using automake will need to arrange for
tarball distribution of these files by hand.
* tests/torture.at (Missing auxiliary files): Test autoreconf as well.
xsystem_hint() executes the command, so there's no need to call xsystem()
afterwards.
* bin/autoreconf.in: No need to call xsystem($cmd) immediately after
calling xsystem_hint("message", $cmd).
Commit 41edf99f95 made all Perl warnings
fatal. This caused autoreconf to crash on packages that call
AC_CONFIG_SUBDIRS with no arguments. They probably shouldn’t do that,
but we shouldn’t crash if they do.
Problem reported by Ross Burton.
* bin/autoreconf.in (autoreconf_current_directory):
Convert undef to '' before attempting to split it.
* tests/torture.at (Empty AC_CONFIG_SUBDIRS): New test.
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 existing check for whether aclocal and
automake understand ‘--warnings’ at all, but it currently assumes that
automake will accept the same set of warnings *categories* that
autoconf does. This hasn’t actually been true for many years
and is known to cause problems; see the discussion starting at
<https://lists.gnu.org/archive/html/autoconf/2020-09/msg00000.html>.
Previous patches in this series (and related patches applied to
automake) have restored agreement between the current development
trunks of the two sets of tools on the set of warnings categories, but
we still need to deal with the possibility of the *installed* tools
not being in agreement.
If we use the WARNINGS environment variable to pass down warnings
options, instead of the command line, then all the tools are already
coded to ignore unknown warning categories, and this ceases to be an
issue. And we no longer need the check for ‘--warnings’ support in
automake, either.
Also, autoreconf as well should suppress warnings from its first
invocation of autoconf, which is for tracing purposes only and may
emit spurious warnings because aclocal.m4 is not yet in place.
* bin/autoreconf.in
($aclocal_supports_warnings, $automake_supports_warnings): Delete.
(@warning): Make local to sub parse_args.
(parse_args): Do not add --warnings options to $autoconf,
$autoheader, $aclocal, or $automake. Instead, set $ENV{WARNINGS}
appropriately. No longer necessary to probe for --warnings support
from aclocal and automake.
(autoreconf_current_directory): Set $ENV{WARNINGS} temporarily to
“none” when running autoconf in trace mode. Fix typo in comment.
Close $traces immediately after we’re done with it.
* tests/torture.at (Specific warnings options for autoreconf):
New test.
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 duplicated.
autoscan doesn’t pass down warnings options but it _does_ leave
the WARNINGS environment variable alone, which means it may issue
completely spurious warnings because the configure script is still
under construction.
Change this so that both programs disable all warnings for the
subsidiary invocation of autoconf, by not passing any warnings
options themselves, and by setting the WARNINGS environment variable
to “none” for the subprocess. For this to work correctly, the
‘args: --warnings syntax’ line has to be removed from autom4te.cfg
(m4sugar section). Since syntax warnings are on by default anyway,
the sole effect of this is to allow WARNINGS=none to turn off syntax
warnings.
The test suite changes are all to remove expectations of duplicate
diagnostics from autoheader.
* bin/autoheader.in: Do not pass warnings options down to subsidiary
autoconf, and set WARNINGS=none in the environment for that process.
* bin/autoscan.in: Set WARNINGS=none in the environment for subsidiary
autoconf.
* lib/autom4te.in (M4sugar): Remove ‘--warnings syntax’.
* tests/semantics.at, tests/torture.at: No longer expect various
diagnostics from autoheader as well as autoconf.
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 *been* in sync for more than 17 years.
This patch manually brings over all of the changes made on the
automake side. Once the complementary patch is applied by the
automake team, both versions of the file will be the same, and then we
can add it to the list in fetch.pl and not have this problem any more
in the future.
There are some user-visible consequences to bringing this file back
into sync. The only one worth mentioning in NEWS is that the ‘obsolete’
category of warnings is now on by default. This had quite a bit of
fallout throughout the testsuite. There are also some new warning
categories that get mentioned in --help output, but we don’t actually
generate any warnings in those categories, so people using ‘-Wall’
won’t see any change. More diagnostics are automatically tagged with
‘warning:’ or ‘error:’, which also had some fallout in the testsuite.
Finally, ‘-Werror’ no longer causes complaints about unknown warning
categories to be treated as hard errors.
Internally, there are some small API changes: ‘parse_warnings’ is no
longer usable as a ‘getopt’ callback function, and we now have a stub
Autom4te/Config.pm to match the automake code’s expectations. (This
file *should* also be synced from automake by ‘make fetch’, but we
can’t quite do that yet because it’s a generated file and our build
system is not prepared to handle adding *two* directories to @INC when
running a not-yet-installed Perl script. I plan to fix that after 2.70.)
As a side-effect of adding a Config.pm, ‘prog_error’ now says to
report the bug to bug-autoconf, not bug-automake. If this is why we
mostly haven’t been using prog_error for internal errors, we can stop
avoiding it. (I did not change anything to use prog_error in this
patch.)
* lib/Autom4te/ChannelDefs.pm: Merge from automake.
* lib/Autom4te/Config.pm: New file.
* lib/local.mk (dist_perllib_DATA): Add Autom4te/Config.pm.
* bin/autoconf.as: Update list of warning categories to match
Autom4te::ChannelDefs::usage.
* bin/autoheader.in (@warnings): New global.
(parse_args): Don’t use parse_warnings as a getopt callback.
(main): Add warnings options from our command line to $autoconf.
No need to turn on 'obsolete' warnings explicitly.
No need to include "warning: " in warning messages.
* bin/autom4te.in (parse_args): Don’t use parse_warnings as a getopt callback.
(main): No need to include "warning: " in warning messages.
* bin/autoreconf.in (parse_args): parse_warnings now takes only one argument.
* bin/autoupdate.in: Set WARNINGS=none in environment for all child processes.
* tests/local.at
(AT_CHECK_M4): Handle `autom4te: error: /usr/bin/m4 ...` like
`autom4te: /usr/bin/m4 ...`.
(_AT_CHECK_AC_MACRO): Add AUTOCONF-FLAGS argument, passed to both
autoconf and autoheader.
(AT_CHECK_MACRO): Default AUTOCONF-FLAGS argument to empty.
Pass that argument to autoheader as well as autoconf.
(AT_CHECK_AU_MACRO): Expect a “macro ‘NAME’ is obsolete’ diagnostic
on the first run of autoconf. Pass -Wno-obsolete to autoconf on the
second run, and to autoheader on both runs.
* tests/base.at
* tests/c.at
* tests/compile.at
* tests/m4sh.at
* tests/m4sugar.at
* tests/semantics.at
* tests/tools.at
* tests/torture.at:
No need to pass -Wobsolete to autoconf.
Pass -Wno-obsolete to autoheader where needed to avoid handling
the same warning twice.
Update various expectations for diagnostics to match behavior
changes.
* tests/tools.at (autoupdating AU_ALIAS): Add an AC_CONFIG_HEADERS
line to the test configure.ac to eliminate an unrelated diagnostic.
Commit 9b5c0f1774 introduced a bug where
autoconf --help would only print “Try 'autoconf --help' for more information.”
Correct this.
* bin/autoconf.as: Print $help, not $usage_err, for --help.
Consistently use AS_ECHO, not bare echo.
At file scope of a file containing at most one ‘package’ declaration,
‘use vars’ is exactly equivalent to ‘our’, and the latter is preferred
starting with Perl 5.6.0, which happens to be the oldest version we
support.
In one place ‘our’ was not actually necessary and was switched to ‘my’.
(This change has already been made in Automake and applied to the
shared Perl code via the previous ‘make fetch’ commit.)
* lib/Autom4te/C4che.pm
* lib/Autom4te/ChannelDefs.pm
* lib/Autom4te/General.pm: Replace all uses of ‘use vars’ with ‘our’.
* bin/autoheader.in: Replace all uses of ‘use vars’ with ‘our’.
Remove an unnecessary ‘local’.
* bin/autoscan.in: Convert ‘use vars’ variables to ‘my’ variables.
Search-and-replace change ‘use warnings;’ to ‘use warnings FATAL => 'all';’
in all Perl code.
Notwithstanding the dire cautions in ‘perldoc warnings’ about this,
I think it’s the right call for us. One file was already doing it.
No new testsuite failures are observed on Linux with Perl 5.30.3
nor on NetBSD with Perl 5.6.1.
* bin/autoheader.in, bin/autom4te.in, bin/autoreconf.in
* bin/autoscan.in, bin/autoupdate.in, bin/ifnames.in
* lib/Autom4te/C4che.pm, lib/Autom4te/ChannelDefs.pm
* lib/Autom4te/Channels.pm, lib/Autom4te/Configure_ac.pm
* lib/Autom4te/FileUtils.pm, lib/Autom4te/General.pm
* lib/Autom4te/Request.pm, lib/Autom4te/XFile.pm:
Make all warnings from the Perl interpreter into fatal errors.
All the Perl scripts and modules now ‘use’ other modules in the
following order:
- use 5.006; use strict; use warnings; in that order.
If a file was not already use-ing one of these three, it was added.
- The BEGIN block that adds the installation directory for the
Autom4te:: modules to @INC, if necessary.
- All stdlib modules whose name begins with a capital letter,
in ASCII sort order.
- All Autom4te:: modules, in ASCII sort order.
- ‘use vars qw (...)’, if any, last.
Also, ‘use foo qw (...)’ and @ISA lists have been sorted into ASCII
sort order. (@EXPORT lists, which often follow immediately after @ISA
lists, have *not* been sorted, as these appear to have been organized
semantically in many cases.) qw delimiters have been normalized to
round parentheses with a space between the qw and the open paren.
* bin/autoheader.in, bin/autom4te.in, bin/autoreconf.in
* bin/autoscan.in, bin/autoupdate.in, bin/ifnames.in
* lib/Autom4te/C4che.pm, lib/Autom4te/ChannelDefs.pm
* lib/Autom4te/Channels.pm, lib/Autom4te/Configure_ac.pm
* lib/Autom4te/FileUtils.pm, lib/Autom4te/General.pm
* lib/Autom4te/Getopt.pm, lib/Autom4te/Request.pm
* lib/Autom4te/XFile.pm: Rationalize order and format of ‘use’
directives and @ISA lists. Add any of ‘use 5.006’, ‘use strict’,
and ‘use warnings’ that was not already present.
Some downstream redistributors for Autoconf wish to use
‘/usr/bin/env perl’ as the #! line for the installed Perl scripts.
This does not work with command-line options on the #! line, as the
kernel doesn’t support supplying more than one argument to a #!
interpreter (this limitation is universal across Unixes that
support #!, as far as I know).
Remove ‘-w’ from all perl #! lines and instead add ‘use warnings’
to all the scripts and .pm files that didn’t already have it.
This ‘use’ directive was added to Perl in version 5.6.0 (aka 5.006)
so there is no change to our minimum Perl requirement.
(It is necessary to add ‘use warnings’ to all the .pm files as well as
the scripts, because the ‘-w’ command-line option turns on warnings
globally, but ‘use warnings’ does so only for the current lexical scope.)
Patch uplifted from OpenEmbedded, originally by Serhii Popovych.
It’s a mechanical search-and-replace change so I do not believe a
copyright assignment is necessary.
* bin/autom4te.in, bin/autoreconf.in, bin/autoscan.in
* bin/autoupdate.in, bin/ifnames.in: Remove -w from #! line
and add ‘use warnings’ to imports.
* lib/Autom4te/C4che.pm, lib/Autom4te/ChannelDefs.pm
* lib/Autom4te/Channels.pm, lib/Autom4te/Configure_ac.pm
* lib/Autom4te/FileUtils.pm, lib/Autom4te/General.pm
* lib/Autom4te/Request.pm, lib/Autom4te/XFile.pm:
Add ‘use warnings’ to imports.
We generate manpages for autoconf’s installed programs (autoconf,
autoheader, etc.) using help2man, which runs each program in order to
learn its --help output. Each manpage therefore has a dependency on
the existence of the corresponding program, but this dependency is
intentionally left out of the Makefile so that one can build from a
tarball release (which will include prebuilt manpages) without having
help2man installed.
But when building from a git checkout with high levels of
parallelism (-j20 or so), the missing dependency can lead to build
failures, because help2man will try to run the program before it
exists. In an earlier patch I tried to work around this with a
recursive make invocation in the ‘.x.1’ rule, to ensure the existence
of the program. That only traded one concurrency bug for another, now
we could have two jobs trying to build the same program simultaneously
and they would clobber each other’s work and the build would still
fail.
Instead, this patch introduces a utility script ‘help-extract.pl’ that
reads --help and --version information directly from the source code
for each program. This utility, wrapped appropriately for each
program, is what help2man now runs. Usage is a little weird because
help2man doesn’t let you specify any arguments to the “executable”
that it runs, but it works, and lets us write all of the true
dependencies of each manpage into the Makefile without naming any file
that would be created during a build from a tarball. help-extract.pl
is a Perl script, so it introduces no new build-time requirements.
A downside is that we have to make sure each of the script sources in
bin/, and also part of lib/Autom4te/ChannelDefs.pm, are parseable by
help-extract. The most important constraints are that the text output
by --help must be defined in a global variable named ‘help’, and its
definition has to be formatted just the way these definitions are
currently formatted. Similarly for --version. Furthermore, only some
non-literal substitutions are possible in these texts; each has to be
explicitly supported in help-extract.pl. The current list of supported
substitutions is $0, @PACKAGE_NAME@, @VERSION@, @RELEASE_YEAR@, and
Autom4te::ChannelDefs::usage.
The generated manpages themselves are character-for-character
identical before and after this patch.
* build-aux/help-extract.pl: New build script that extracts --help
and --version output from manpages.
* man/autoconf.w, man/autoheader.w, man/autom4te.w, man/autoreconf.w
* man/autoscan.w, man/autoupdate.w, man/ifnames.w: New shell scripts
which wrap build-aux/help-extract.pl.
* man/local.mk: Generate each manpage by running help2man on the
corresponding .w script, not on the built utility itself.
Revise all dependencies to match.
* bin/autoconf.as: Rename ‘usage’ variable to ‘help’ and
‘help’ variable to ‘usage_err’.
* bin/autoheader.in: Call Autom4te::ChannelDefs::usage with no
function-call parentheses, matching all the other scripts.
* bin/autom4te.in: Initialize $version with a regular double-quoted
string, not a heredoc, matching all the other scripts.
* bin/autoscan.in: Remove global variable $configure_scan.
In addition to the gtkdocize tool, gtk-related software may utilize the
IT_PROG_INTLTOOL macro in order to require the intltoolize tool. So too
here should the tool be run by autoreconf itself, in order to guarantee
its initialization via the unified frontend for all autotools projects.
When the GTK_DOC_CHECK macro is in use, this flags a given configure.ac
as belonging the the common class of gtk-related software that requires
the gtkdocize tool to be run before autoreconf, in order to install the
gtk-doc macro and Makefile fragment. Make this easier to accomplish via
teaching autoreconf how to detect and run this tool automatically; this
gets us one step closer to a world in which `autoreconf -fi` on its own
is enough to bootstrap any autotools project into a configurable state.
It is almost always incorrect for a configure script to omit either
AC_INIT or AC_OUTPUT. Issue warnings in the ‘syntax’ category for
this.
The implementation is, unfortunately, a bit of a kludge. To check for
the _absence_ of a macro invocation, we can use m4_provide_if inside a
m4_wrap hook. However, if we activate the m4_wrap hook directly from
general.m4, we get spurious warnings at freeze time. We also get
warnings whenever a script that’s missing AC_INIT and/or AC_OUTPUT
is *traced*, which means we get double warnings from autoconf, and
autoheader and aclocal complain about it too, which seems unnecessary.
A clean way to deal with this would be to make the hook look for a
special macro that’s defined only when autoconf (the program) is
invoked without any --trace arguments. Unfortunately, autom4te
doesn’t pass --define down to M4, and changing that would involve
coordinating with Automake (the project), so instead I’ve gone for the
kludge: a new file lib/autoconf/trailer.m4 that calls m4_wrap. This
file is *not* included in autoconf.m4f, but it’s installed, and it’s
added to the m4 invocation by autoconf (the program) only when not
tracing. (It still uses m4_wrap, because we pass it to m4 *before*
configure.ac, because otherwise we get nonsense locations for any
*other* diagnostics coming out of this autoconf invocation. I don’t
know why.)
The additional checks in autoreconf are intended to make sure that if
autoreconf skips a directory entirely, you get told why.
Lots of tests in the testsuite didn’t bother with AC_OUTPUT, and
somewhat fewer didn’t bother with AC_INIT; where possible I just added
them.
Suggested by David A. Wheeler, who submitted a patch, but I didn’t
wind up using any of his code. (His implementation used an extra
tracing pass, only checked for a missing AC_INIT, and invented a new
command-line option to turn off this specific warning. I thought this
was tidier overall, despite the kludge.)
* lib/autoconf/general.m4 (_AC_FINALIZE): New macro: code to be run
when generating configure, after the entire configure.ac is
processed. Currently only checks that AC_INIT and AC_OUTPUT were
called at some point, issuing syntax-category warnings if not.
(AC_INIT, AC_OUTPUT): m4_provide self.
* lib/autoconf/trailer.m4: New file that just calls m4_wrap([_AC_FINALIZE]).
* lib/local.mk: Install new file.
* bin/autoconf.as: Add trailer.m4 to the final invocation of autom4te,
but only when not tracing.
* bin/autoreconf.in (autoreconf_current_directory): Distinguish in
diagnostics between “directory skipped because it doesn’t have a
configure.ac or configure.in” (e.g. Cygnus configure) and “directory
has a configure.ac but it doesn’t appear to be autoconf input.”
* tests/*.at: Fix all tests affected by the new warnings.
* bin/autoheader.in (templates_for_header): Fix previous change by
not warning about file names with shell metacharacters, as this is
OK for command-line file names.
Problem reported by Ken Moffat (sr#110287); the problem was
introduced in 2016-12-21T16:15:46Z!daniel.kitta@gmail.com.
* bin/autoheader.in (templates_for_header):
When generating warnings about symbols lacking templates,
downgrade template read failure from a fatal error to a warning.
Also, don’t even try to read from a template file whose name has
shell metavariables (which Autoconf 2.50 withdrew support for);
just warn about that, too. These changes cause the Automake
tests to merely generate warnings that are ignored, instead
of failing.
* doc/autoconf.texi (Configuration Files, Configuration Headers)
(Configuration Commands, Configuration Links):
Also document here that the file names should not contain
shell metacharacters, to make this constraint more obvious.
Problem reported in <https://bugs.debian.org/219621>.
* bin/autom4te.in: Save and check autom4te version number into cache index.
* lib/Autom4te/C4che.pm (save): New arg $version. All callers changed.
(good_version): New sub.
This helps out dh-autoreconf on Debian
<https://bugs.debian.org/759739>.
* bin/autoreconf.in (autoreconf_current_directory):
* lib/autom4te.in (args): Look for AM_PROG_LIBTOOL too.
Copyright-paperwork-exempt: Yes
