Zack Weinberg [Fri, 4 Dec 2020 21:32:35 +0000 (16:32 -0500)]
Revert "AC_PROG_CC: define via AC_DEFUN_ONCE". (#110350)
Revert commit 18c140b50b0619454d4da50d58a318cc257d580a, restoring
AC_PROG_CC to being defined as an ordinary AC_DEFUN. This broke
third-party macros (e.g. the Autoconf Macro Archive’s
AX_PROG_CC_FOR_BUILD) that intentionally invoked AC_PROG_CC a second
time with its guts redefined via a whole bunch of ‘pushdef’s. I don’t
think we want to support this long-term, but needing access to a
build-native compiler in cross-compilation is common enough that we
should have *some* supported way to do it, and it may as well be
AX_PROG_CC_FOR_BUILD until we come up with something better.
If we go back to AC_DEFUN_ONCE for AC_PROG_CC in the future, we should
do it consistently for all the “find me a compiler” macros -- it
was *only* done for AC_PROG_CC in 18c140b5.
The rationale for AC_DEFUN_ONCE seems to have been to reduce the size
of the generated configure script. The bulk of the size accountable to
AC_PROG_CC is the test programs for figuring out which version of the
C standard is available, so I tweaked _AC_C_STD_TRY (and _AC_CXX_STD_TRY)
to emit that text only once per program, into shell variables which
can then be referenced repeatedly.
Fixes bug #110350.
* NEWS, doc/autoconf.texi: Revert documentation changes associated
with AC_PROG_CC being a one-shot macro.
* lib/autoconf/c.m4 (AC_PROG_CC): Revert to defining with AC_DEFUN.
(_AC_C_STD_TRY, _AC_CXX_STD_TRY): Emit the test program only once,
even if invoked multiple times with the same arguments.
* tests/foreign.at (AX_PROG_CC_FOR_BUILD, AX_PROG_CXX_FOR_BUILD):
New tests.
Zack Weinberg [Wed, 28 Oct 2020 21:04:22 +0000 (17:04 -0400)]
Autotest: add official way to execute code before all/each test.
Currently, there isn’t any documented way for an Autotest testsuite to
add custom code to be run either right before the main driver loop, or
at the point of each AT_SETUP. For instance, there’s no good place to
put environment variable sanitization that should apply to the entire
testsuite (but isn’t universally relevant), or shell function
definitions to be used by custom test macros.
Autoconf’s test suite is poking shell functions directly into the
PREPARE_TESTS diversion, and doing environment variable sanitization
in each individual test. Both of these are obviously undesirable.
This patch adds three new AT_* macros that can be used to do these
things in an officially-supported way: AT_PREPARE_TESTS adds code to
be run right before the main driver loop, AT_PREPARE_EACH_TEST adds
code to be run at the beginning of each test, and AT_TEST_HELPER_FN
defines a shell function that will be available to each test. In
Autoconf’s test suite, I use AT_PREPARE_TESTS to factor out
environment variable sanitization that *ought* to apply across the
board, and AT_TEST_HELPER_FN for the helper function used by
AT_CHECK_ENV.
(This fixes the testsuite bug reported by Jannick at
https://lists.gnu.org/archive/html/autoconf/2020-10/msg00052.html :
CONFIG_SITE in the parent environment will no longer be visible to tests.)
It would be nice to give an example of when AT_PREPARE_EACH_TEST is
useful, in the documentation, but I didn’t find one in the autoconf
test suite.
* lib/autotest/general.m4 (AT_PREPARE_TESTS, AT_PREPARE_EACH_TEST)
(AT_TEST_HELPER_FN): New macros.
(AT_INIT, AT_TESTED): Emit the code to report tested programs only
if it’s needed, and make sure it’s after any code added by
AT_PREPARE_TESTS.
* tests/local.at: Add AT_PREPARE_TESTS block that ensures
$MAKE is set sensibly and $MAKEFLAGS and $CONFIG_SITE are unset.
Use AT_TEST_HELPER_FN for the helper function needed by AT_CHECK_ENV.
(AT_CHECK_MAKE): No need to sanitize $MAKE or $MAKEFLAGS here.
* tests/base.at, tests/compile.at, tests/m4sh.at, tests/torture.at:
No need to unset or neutralize $CONFIG_SITE in individual tests.
* tests/autotest.at: Add tests for new macros.
Bruno Haible [Tue, 1 Dec 2020 21:42:17 +0000 (22:42 +0100)]
Document better where to put -m32 or -m64 compiler options.
* doc/autoconf.texi (Preset Output Variables): Clarify that options -m32 or -m64
must go into CC, not CFLAGS and not CPPFLAGS either. This is needed because on
bi-arch platforms, config.guess runs $CC without $CFLAGS nor $CPPFLAGS.
Zack Weinberg [Mon, 30 Nov 2020 23:06:26 +0000 (18:06 -0500)]
Make autoreconf --force --install overwrite existing files (#110371)
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.
Zack Weinberg [Wed, 14 Oct 2020 15:21:30 +0000 (11:21 -0400)]
AT_CHECK_MACRO: test C++ as well as C, cross as well as native
Many of the reported regressions in Autoconf 2.70 betas went unnoticed
for years because Autoconf’s bundled test suite didn’t test most of
the macros with a C++ compiler and/or in cross compilation mode.
There’s a special makefile target ‘maintainer-check-c++’ that runs all
the tests with CC=g++, but that doesn’t catch the regressions either,
because it doesn’t compare the configure results with what you’d have
gotten with a C compiler. Also, C and C++ have diverged to the point
where setting CC to a C++ compiler doesn’t work reliably anymore.
This patch overhauls AT_CHECK_MACRO to test each macro four times:
(C compiler, C++ compiler) x (native mode, cross-compilation mode).
All four tests are expected to produce the same config.cache and
config.h, except for certain predictable differences due to running
AC_PROG_CXX instead of AC_PROG_CC, and a short list of known,
acceptable differences, maintained in mktests.pl.
There are two classes of known, acceptable differences. Macros that
use AC_RUN_IFELSE aren’t tested in cross-compilation mode at all,
because they may crash the script (this is temporary and will be
revisited after 2.70). Macros that correctly detect a difference
between C and C++ (e.g. AC_HEADER_STDBOOL will notice that C++ doesn’t
have the _Bool type) are annotated with the specific cache variable
and #define that varies.
mktests.pl now also has the capability to provide values for the
MACRO-USE, ADDITIONAL-COMMANDS, and AUTOCONF-FLAGS arguments to
AT_CHECK_(AU_)MACRO, on a per-macro basis, but that’s not used in this
patch.
Some of the manual uses of AT_CHECK_MACRO do not need to test C++
and/or cross compilation; for them, there is a new test helper,
AT_CHECK_CONFIGURE_AC. Another new helper, AT_PRESERVE_CONFIG_STATUS,
is used extensively in AT_CHECK_(AU_)MACRO but may be also useful in
manual tests that need to do multiple configure runs.
This change supersedes AT_CHECK_MACRO_CROSS and
‘make maintainer-check-c++’, which are removed.
In my testing, setting CC to a C++ compiler no longer works at all,
for reasons that are impractical to fix (e.g. C++ compilers choke on
the test for C2011 features) so I have added a note to NEWS saying
that this is not supported anymore.
* tests/local.at (AT_CHECK_MACRO): Default behavior is now to test
the macro in both native and cross-compilation mode, and expect the
results to be identical. If the macro transitively required
AC_PROG_CC, and a C++ compiler is available, then test it twice
more with AC_LANG([C++]) in effect, and again expect the results to
be identical. New fifth argument TEST-PARAMETERS can modify this
behavior.
(_AT_FILTER_CXX_CV_VARIES, _AT_FILTER_CXX_DEFINE_VARIES): New,
subroutines of AT_CHECK_MACRO.
(AT_CHECK_MACRO_CROSS): Remove, subsumed by new AT_CHECK_MACRO
behavior.
(AT_CHECK_AU_MACRO): Forward to AT_CHECK_MACRO for the basic test;
then do the same autoupdate test as before, as a separate test group.
(at_check_env): Also ignore OPENMP_CXXFLAGS.
(AT_CONFIG_CMP): Add third argument EXTRA-VARIANCE that specifies
additional variables that are expected to vary in a particular test.
(_AT_CONFIG_CMP_PRUNE): New, subroutine of AT_CONFIG_CMP.
(AT_DEFINES_CMP): New helper macro that compares config.h headers,
with the ability to ignore variation in specific defines.
(_AT_DEFINES_CMP_PRUNE): New, subroutine of AT_DEFINES_CMP.
(AT_PRESERVE_CONFIG_STATUS): New helper that makes copies of
config.h, config.log, config.status, and state-env.after under
names that won’t be clobbered by a subsequent run of configure.
(AT_CHECK_CONFIGURE_AC): New helper that defines a complete test
group consisting of a single invocation of _AT_CHECK_AC_MACRO;
effectively what AT_CHECK_MACRO used to be.
(_AT_CHECK_AC_MACRO): Correct documentation comment; the PRE-TESTS
argument has always been optional.
* tests/mktests.pl (test_parameters): New global data object giving
extra arguments to pass to AT_CHECK_MACRO/AT_CHECK_AU_MACRO on a
per-macro basis.
(emit_test): New function that handles emitting calls to
AT_CHECK_(AU_)MACRO with the desired arguments.
(scan_m4_files): Use emit_test.
(au_exclude_list): Add AC_HAVE_LIBRARY, AC_COMPILE_CHECK,
AC_TRY_CPP, AC_TRY_COMPILE, AC_TRY_LINK, and AC_TRY_RUN.
* tests/semantics.at (AC_CHECK_LIB, AC_SEARCH_LIBS): Rewrite test
using symbols from zlib instead of libm, to get consistent behavior
from C and C++.
(AC_SEARCH_LIBS (none needed)): Revise to clarify what is being tested.
(AC_CHECK_DECLS): Use _AC_LANG_ABBREV when inspecting cache variables.
(AC_CHECK_ALIGNOF, AC_CHECK_ALIGNOF struct)
(AC_CHECK_SIZEOF, AC_CHECK_SIZEOF struct)
No need for AT_CHECK_MACRO_CROSS.
(AC_CHECK_FILES): Switch to AT_CHECK_CONFIGURE_AC.
(AC_SYS_RESTARTABLE_SYSCALLS, AC_FUNC_WAIT3): Do not test in cross
compilation mode.
(AC_TRY_CPP, AC_TRY_COMPILE, AC_TRY_LINK, AC_TRY_RUN)
(AC_COMPILE_CHECK, AC_HAVE_LIBRARY): New manual AT_CHECK_AU_MACRO tests.
* tests/c.at (Extensions, C keywords, AC_PROG_CPP requires AC_PROG_CC)
(AC_NO_EXECUTABLES (working linker), AC_NO_EXECUTABLES (broken linker)):
Switch to AT_CHECK_CONFIGURE_AC. Also convert case statements to AS_CASE.
(Broken/missing compilers): Pass CC=no-such-compiler on the command
line instead of hardwiring it in the configure script.
* tests/local.mk (maintainer-check-c++): Remove target.
(maintainer-check): Run the ordinary ‘make check’ as well as
‘make maintainer-check-posix’.
Zack Weinberg [Sat, 10 Oct 2020 19:47:01 +0000 (15:47 -0400)]
Rewrite mktests.sh in Perl.
This is probably marginally faster since it doesn’t have to read the
.m4 files twice or muck around with temporary files and subprocesses,
but the actual point of this rewrite is that it will make it easier to
provide additional arguments to AT_CHECK_MACRO and AT_CHECK_AU_MACRO
on a per-macro basis; this capability will be added and used in the
next patch.
In *this* patch, the ac*.at files are not functionally changed at all.
(The comments come out slightly differently, though.)
* tests/mktests.sh: Delete and...
* tests/mktests.pl: ...rewrite in Perl.
* tests/local.mk: Update to match.
Zack Weinberg [Wed, 7 Oct 2020 19:45:57 +0000 (15:45 -0400)]
Overhaul Erlang support.
Erlang is similar to Java in that it doesn’t compile to standalone
machine code; the output of ‘erlc’ is byte-code files that are then
interpreted by ‘erl’. We handle this poorly in a whole bunch of ways,
particularly when cross-compiling. This patch fixes up the more
serious problems:
- AC_COMPILE_IFELSE now actually works when AC_LANG([Erlang]) is in
effect.
- ‘conftest.beam’ is now deleted in several more places where it
could be created.
- The various AC_ERLANG_* macros that interrogate the runtime
environment do so by invoking ‘$ERL’ directly, rather than using
AC_RUN_IFELSE, and thus do not crash the configure script when
we think we’re cross-compiling. (It is not clear to me whether
they get the correct answer when cross-compiling, but this should
still be strictly an improvement.)
- The Erlang-related tests have been streamlined.
Further improvements are definitely possible, but we’d have to teach
the infrastructure to make $ac_objext language-specific first, which
seems like too big of a change for 2.70.
(This patch is all fallout from a logically unrelated testsuite change
which is coming up next. Gotta love the fundamental interconnectedness
of things.)
* lib/autoconf/general.m4 (_AC_COMPILE_IFELSE_BODY)
(_AC_LINK_IFELSE_BODY): Delete conftest.beam as well as conftest.$ac_objext.
* lib/autoconf/erlang.m4 (AC_ERLANG_PATH_ERLC, AC_ERLANG_PATH_ERL):
Don’t repeat work done by AC_PATH_TOOL.
(Erlang $ac_compile): Fake an .o file so AC_TRY_COMPILE will be happy.
(AC_LANG_COMPILER(Erlang)): AC_REQUIRE AC_ERLANG_NEED_ERLC, not
AC_ERLANG_PATH_ERLC. Also AC_REQUIRE AC_ERLANG_NEED_ERL so
AC_RUN_IFELSE works reliably.
(AC_ERLANG_CHECK_LIB, AC_ERLANG_SUBST_ROOT_DIR)
(AC_ERLANG_SUBST_LIB_DIR, AC_ERLANG_SUBST_ERTS_VER):
Use $ERL -eval, not AC_RUN_IFELSE.
No need to AC_REQUIRE AC_ERLANG_NEED_ERLC.
* tests/erlang.at: Don’t test anything here that’s tested adequately
by acerlang.at; document which macros those are expected to be.
Remove unnecessary AC_ERLANG_PATH_ERL/ERLC invocations throughout.
(AT_CHECK_MACRO([Erlang])): Rename test to ‘Erlang basic compilation’;
expect both AC_COMPILE_IFELSE and AC_RUN_IFELSE to work;
handle cross compilation mode properly.
* tests/mktests.sh: Exclude from acerlang.at all macros completely
covered by erlang.at.
Zack Weinberg [Mon, 30 Nov 2020 14:26:37 +0000 (09:26 -0500)]
Make “redefining AS_ECHO internals” test more robust.
M4-redefining ‘printf’ as ‘echo’ brings back all the variations in
‘echo’ behavior that we were trying to get away from by switching to
‘printf’ in the first place. This caused a spurious failure on AIX.
* tests/m4sh.at (Redefining AS_ECHO internals): Redefine ‘printf’ as
a shell function with fully predictable output, not as ‘echo’.
Zack Weinberg [Sat, 28 Nov 2020 16:18:05 +0000 (11:18 -0500)]
torture.at: Insulate more tests from buggy third-party m4 files.
All tests that run autoreconf need to defend against the possibility
of aclocal not existing and/or barfing on bugs in third-party m4 files
installed on the build system. Two of the “Missing auxiliary files”
tests were missing this defensive code.
Zack Weinberg [Mon, 30 Nov 2020 16:26:06 +0000 (11:26 -0500)]
Avoid ‘new File::Temp’ in Perl scripts.
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.
Zack Weinberg [Sat, 28 Nov 2020 16:08:28 +0000 (11:08 -0500)]
Disentangle HAVE__BOOL from ac_cv_header_stdbool_h.
AC_CHECK_HEADER_STDBOOL is documented to make two checks: whether the
C99 header <stdbool.h> is available and fulfills its
specification (i.e. including it makes the type ‘bool’ and the
constants ‘true’ and ‘false’ available), and, independently, whether
the type ‘_Bool’ is available.
In C++, the type ‘_Bool’ is usually _not_ available, but <stdbool.h>
is still supposed to be include-able and the type ‘bool’ and the
constants ‘true’ and ‘false’ are still supposed to be available
(unconditionally). However, the test for <stdbool.h> fulfilling its
specification freely used _Bool, and would therefore fail spuriously.
Correct this by checking for _Bool first, and then refactoring the
test program for <stdbool.h> so that it does all its tests using bool,
then repeats them with _Bool only when available.
* lib/autoconf/headers.m4 (AC_CHECK_HEADER_STDBOOL): Do the test for
_Bool before the test for stdbool.h. Test semantics of bool
unconditionally; test _Bool only when HAVE__BOOL is defined.
Zack Weinberg [Sat, 28 Nov 2020 15:01:31 +0000 (10:01 -0500)]
AC_FUNC_SETPGRP: Don’t depend on the return type of setpgrp.
AC_FUNC_SETPGRP determines whether you have the historic BSD setpgrp,
which takes two arguments and returns int, or the historic POSIX
setpgrp, which takes no arguments and returns int. Solaris has yet a
third variant, which takes no arguments and returns a pid_t (the new
process group ID). This difference causes AC_FUNC_SETPGRP’s test
program to fail to compile under AC_LANG([C++]), which in turn causes
the macro to report that setpgrp does take arguments, which is wrong.
It is not worth adding a new result #define for this variant,
since *all* forms of setpgrp are deprecated in favor of setpgid, which
is old enough that it can be used unconditionally. However, it is
worth documenting that this variant exists, and fixing AC_FUNC_SETPGRP
to produce the right value for its existing result #define on Solaris
with C++.
* lib/autoconf/functions.m4 (AC_FUNC_SETPGRP): Redesign test program to
not depend on the return type of setpgrp.
* doc/autoconf.texi (AC_FUNC_SETPGRP): Mention that the macro does not
check for the Solaris variant of setpgrp that returns pid_t. Change
programming advice to recommend use of setpgid.
Zack Weinberg [Mon, 30 Nov 2020 15:49:35 +0000 (10:49 -0500)]
AC_C_CHAR_UNSIGNED: Remove check of $GCC.
On systems where plain ‘char’ is unsigned (e.g. AIX) we would define
__CHAR_UNSIGNED__ only when $GCC was not true at configure time.
If AC_LANG([C++]) has been in effect since the beginning of the
script (so AC_PROG_CC was never invoked), $GCC will be false
regardless; this causes an inconsistency between the C and C++
behaviors, even when both compilers are GNU.
The point of checking $GCC here is that GCC has command line options
to override the signedness of plain ‘char’, and it predefines
__CHAR_UNSIGNED__ to indicate what the signedness actually is.
We don’t want config.h to override that. However, there is already
a special autoheader template for __CHAR_UNSIGNED__ that prevents it
being redefined if it’s defined already, so checking $GCC at
configure time is redundant and can safely be removed.
* lib/autoconf/c.m4 (AC_C_CHAR_UNSIGNED): Do not make result depend on
value of $GCC. Adjust commentary.
Zack Weinberg [Sat, 28 Nov 2020 17:22:09 +0000 (12:22 -0500)]
sc_error_message_uppercase: allow fully uppercased words
If an error message starts with an entire fully uppercased word,
that’s probably a proper noun and it should stay that way. For
instance, autoreconf has an error message that starts with
"AM_GNU_GETTEXT is used, but ..."; AM_GNU_GETTEXT is the name of an
Automake macro, it needs to stay uppercased.
This subsumes the existing exception for the words FATAL and WARNING.
While I was in there I generalized the exception for PRIuMAX to cover
all of the inttypes.h PRI* and SCN* macros.
This patch has been submitted to Gnulib; until it is merged there,
anyone running ‘make fetch’ should take care not to drop this change.
* maint.mk (sc_error_message_uppercase): Allow error messages that
begin with any fully uppercased word, or with any of the inttypes.h
PRI[dioux]\w+ or SCN[dioux]\w+ macros.
Zack Weinberg [Wed, 14 Oct 2020 22:03:21 +0000 (18:03 -0400)]
AC_INIT: better handling of unusual arguments (#110349)
Fix some subtle quotation bugs in _AC_INIT_PACKAGE that made it
impossible to put ‘,’ or an unbalanced close parenthesis in some of
the arguments to AC_INIT. Document that arguments to AC_INIT
containing parentheses, square brackets, ‘,’ or ‘#’ may need to be
double-quoted. Provide more detailed examples and exposition re
computing the arguments to AC_INIT when autoconf is run (e.g. with
git-version-gen). Add a whole bunch more tests for unusual arguments
to AC_INIT, and a test that the backward-compatibility behavior of
AC_INIT with only one argument is still correct.
This may still break some of the existing configure scripts described
in the threads at
https://lists.gnu.org/r/autoconf/2020-10/msg00013.html and
https://lists.gnu.org/r/bug-autoconf/2020-10/msg00012.html
but, I hope, only in ways covered by the existing warning in NEWS
about pickier M4 quotation.
* lib/autoconf/general.m4 (_AC_INIT_PACKAGE): Redo argument
normalization and default value selection in a simpler, less
error-prone fashion.
(_AC_INIT_PACKAGE_N): New helper subroutine.
(AC_INIT): Always call _AC_INIT_PACKAGE, but supply no arguments if
we were called with only one argument.
* tests/base.at (AC_INIT (obsolete invocation)): New test.
(AC_INIT with unusual version strings): Expand test.
Zack Weinberg [Mon, 16 Nov 2020 15:03:39 +0000 (10:03 -0500)]
AS_ECHO(_N): Do not expand macros named ‘s’ or ‘n’ (#110377)
AS_ECHO expands to ‘printf "%s\n" $1’. If a configure script defines
an M4 macro named ‘s’ or ‘n’ it will be expanded in the first argument
to printf, which is almost certainly not what was intended.
The configure script for ruby 2.7.2 uses ‘AS_VAR_PUSHDEF([s], ...)’
and breaks with 2.69d because of this.
Add some extra quoting so that the ‘%s\n’ is treated as literal;
similarly for AS_ECHO_N and the legacy shell variables $as_echo
and $as_echo_n.
For now, anyway, don’t quote the word ‘printf’; if someone does
define that as a M4 macro they might well mean to affect AS_ECHO.
(Whether this is something we *want* to allow, we can worry about
when it comes up.)
Fixes bug #110377.
* lib/m4sugar/m4sh.m4 (_AS_ECHO_N_PREPARE, AS_ECHO, AS_ECHO_N):
Add another layer of quoting around the first argument to printf.
* tests/m4sh.at (Redefining AS_ECHO internals): New test.
Zack Weinberg [Sun, 15 Nov 2020 19:27:38 +0000 (14:27 -0500)]
Don’t issue obsoletion warnings for AC_LANG_SAVE/RESTORE (#110375)
The most recently released version of libtool.m4 is five years old as
of this commit, and no new release is likely to appear anytime soon.
It uses AC_LANG_SAVE and AC_LANG_RESTORE, in a way that doesn’t
obviously translate to AC_LANG_PUSH and AC_LANG_POP. This will need
to be fixed by libtool upstream. Until that actually happens, disable
the -Wobsolete warnings for AC_LANG_SAVE and AC_LANG_RESTORE. (They
are still documented as obsolete in the manual, as they have been for
many years.)
Fixes bug #110375.
* lib/autoconf/lang.m4 (AC_LANG_SAVE, AC_LANG_RESTORE): Define with
AC_DEFUN, not AU_DEFUN; remove manual -Wobsolete warnings.
Zack Weinberg [Sun, 15 Nov 2020 18:56:18 +0000 (13:56 -0500)]
AS_IF: Handle else clause being empty after macro expansion (#110369)
AS_IF can emit a syntactically invalid shell if-then-else,
if CONDITION
then :
# ...
else
fi
when its IF-FALSE argument consists of macros that don’t produce any
shell code. This was a documented limitation in AS_IF, but it’s a bad
limitation to have, because macros that *used* to expand to shell
commands might start expanding to nothing in future releases. For
instance, this broke the libzmq configure script, which did
Perfectly valid in 2.69, but in 2.70 AC_PROG_CC_C99 doesn’t produce
any shell code and the script crashes.
We had that limitation for good reason: we can’t just put ‘:’ at the
beginning of the else-clause, like we do for the then-clause, because
that would clobber $? and the IF-FALSE commands might want to inspect
it. (This doesn’t matter for the then-clause, because $? is always
zero at the beginning of a then-clause anyway.) The simplest and
least inefficient shell construct I can find that works in this
context is a shell function that does ‘return $?’. Due to awkward
M4sh initialization ordering constraints (AS_IF gets used before we
can safely use shell functions) an indirection through a shell
variable is necessary. The structure of a m4sh script is now
#! /bin/sh
## M4sh Initialization
as_nop=:
...
## M4sh Shell Functions
as_fn_nop () { return $?; }
as_nop=as_fn_nop
...
and AS_IF emits
if CONDITION
then :
# ...
else $as_nop
# ...
fi
The uses of AS_IF that appear before the beginning of the M4sh Shell
Functions section are all under our control and they don’t need to
look at $?.
If anyone has a better idea for how to make this work I will be glad
to hear it.
Fixes bug #110369.
* lib/m4sugar/m4sh.m4
(_AS_IF_ELSE): When $1 is nonempty, invoke _AS_EMPTY_ELSE_PREPARE.
Emit $as_nop at beginning of else clause.
(_AS_BOURNE_COMPATIBLE): Initialize as_nop to ‘:’.
(_AS_EMPTY_ELSE_PREPARE): New macro which emits a definition of
as_fn_nop and resets as_nop to as_fn_nop.
(AS_PREPARE, _AS_PREPARE): Invoke _AS_EMPTY_ELSE_PREPARE.
(_AS_UNSET_PREPARE): Tweak white space.
* tests/m4sh.at (AS_IF and AS_CASE): Test AS_IF’s IF-FALSE argument
being empty after macro expansion.
* doc/autoconf.texi (AS_IF): Remove warning about use with
‘run-if-false’ argument empty after macro expansion.
Ross Burton [Wed, 11 Nov 2020 16:19:41 +0000 (11:19 -0500)]
Support CONFIG_SITE being a list of entries.
Instead of treating CONFIG_SITE as a single path, treat it as a
space-separated list of paths and load them in order.
Also remove the special-casing of entries starting with a dash, this is
redundant as they'll be caught by the wildcard case.
Finally add a test case to verify that multiple files are loaded
correctly.
* lib/autoconf/general.m4 (AC_SITE_LOAD): Treat CONFIG_SITE as a
space-separated list of scripts to be sourced. Simplify handling
of default config.site locations using this capability.
* tests/base.at (AC_CACHE_CHECK): Test loading of multiple site files.
* doc/autoconf.texi (Site Defaults): Update documentation of CONFIG_SITE.
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.
Zack Weinberg [Mon, 9 Nov 2020 20:15:23 +0000 (15:15 -0500)]
m4sh: Require shell to support $(...) command substitution.
As of the 2020-11-07 update, config.sub and config.guess
unconditionally use $(...) command substitution; see
<https://lists.gnu.org/archive/html/config-patches/2020-11/msg00011.html>.
Therefore, add this to the set of required shell features, searched
for by _AS_DETECT_BETTER_SHELL. On a system where /bin/sh doesn’t
support $(...), $CONFIG_SHELL will be set to one that does (and the
primary configure script will be re-executed using that shell).
AC_CANONICAL_* use $CONFIG_SHELL to execute config.guess/sub, so they
will keep working. This also means that configure scripts and
third-party macros that use $(...) will quietly start working
correctly on such ancient systems.
The test code is simple, but sufficient to weed out Solaris 10’s
/bin/sh, which doesn’t support $(...) but *does* support shell
functions.
I’m not going to touch any of the existing uses of `...` command
substitution in Autoconf proper for now, but it might make sense to
bulk upgrade them early in the 2.71 release cycle; if nothing else,
it would remove a major obstacle to running shellcheck over our
scripts.
* lib/m4sugar/m4sh.m4 (_AS_MODERN_CMDSUBST_WORKS): New macro.
(AS_INIT, AS_SHELL_SANITIZE): Call _AS_DETECT_REQUIRED for
_AS_MODERN_CMDSUBST_WORKS.
* NEWS: Mention the requirement for $(...).
Zack Weinberg [Mon, 9 Nov 2020 18:44:49 +0000 (13:44 -0500)]
Check in install-sh as synced from automake (#110368)
As pointed out in sr #110368, since install-sh is now being installed
as part of autoconf, we should make sure to ship the latest version
rather than the version shipped by the automake that was used to
bootstrap the autoconf release tarball.
The build-aux/fetch.pl script is already supposed to fetch the latest
version, but install-sh is listed in .gitignore so any updates are
discarded when starting from a clean tree. Correct this.
At the same time, since mdate-sh is *not* installed by autoconf nor is
it directly referenced in any code maintained in the autoconf
repository, remove it from the list of files to fetch and keep it in
.gitignore.
This change exposed a bug in fetch.pl where it would crash when
there was no old copy of a file being updated.
* .gitignore: Remove /build-aux/install-sh.
* build-aux/fetch.pl (%to_fetch): Remove build-aux/mdate-sh.
(slurp): Don’t die on ENOENT, return undef.
(replace_if_change): Handle $oldcontents being undef.
* build-aux/install-sh: Is now checked in.
Michał Górny [Fri, 16 Oct 2015 10:53:55 +0000 (12:53 +0200)]
autoreconf: Support AM_GNU_GETTEXT_REQUIRE_VERSION
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.
Zack Weinberg [Mon, 9 Nov 2020 18:08:13 +0000 (13:08 -0500)]
Fix more bugs in specific tests under AC_LANG(C++).
Found by exhaustive testing for differences between probe results
under AC_LANG(C) and AC_LANG(C++).
* lib/autoconf/c.m4 (AC_C_FLEXIBLE_ARRAY_MEMBER): Cast result of
malloc for C++ compatibility.
* lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL): Declare yywrap
as extern "C" when compiling as C++.
Zack Weinberg [Thu, 5 Nov 2020 15:24:08 +0000 (10:24 -0500)]
Make ‘forbidden tokens, basic’ test more robust.
While testing the previous patch I noticed that the ‘forbidden tokens,
basic’ test can fail if it runs too fast, because the autom4te cache
files aren’t considered newer than configure.ac.
* tests/tools.at (forbidden tokens, basic): Add delays to ensure
autom4te.cache files are newer than configure.ac.
Zack Weinberg [Thu, 5 Nov 2020 15:19:26 +0000 (10:19 -0500)]
Do not apply --program-transform-name to build-aux scripts.
autoreconf expects to find $(pkgdatadir)/build-aux/config.sub etc
under those names, not names modified by --program-transform-name.
Placing them in $(pkgdatadir) is sufficient to keep parallel
installations of autoconf separate: anyone doing that would need
to adjust @PACKAGE@ anyway.
* lib/local.mk: Use a _DATA rule, not a _SCRIPTS rule, to install
config.guess, config.sub, and install-sh.
(install-data-hook-make-aux-scripts-executable): New hook rule.
Zack Weinberg [Thu, 5 Nov 2020 13:59:46 +0000 (08:59 -0500)]
Define AC_REQUIRE_AUX_FILE with AC_DEFUN.
Some widely used Automake recipes involve putting AC_REQUIRE_AUX_FILE
at top level of a configure script, and it uses AC_REQUIRE now, so it
needs to be defined with AC_DEFUN.
* lib/autoconf/general.m4 (AC_REQUIRE_AUX_FILE): Define with AC_DEFUN.
* tests/torture.at (Missing auxiliary files (foreign)): New test.
Zack Weinberg [Mon, 2 Nov 2020 22:16:00 +0000 (17:16 -0500)]
autoreconf.in: improve compatibility with old perl
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.
Zack Weinberg [Mon, 2 Nov 2020 21:56:32 +0000 (16:56 -0500)]
Revert to 2.69-compatible behavior in AC_PROG_LEX (#110346)
Commit 29ede6b96feee29c0c477d1659081bbdb82cd8b3 caused AC_PROG_LEX to
stop looking for a library that provides yywrap. This broke several
packages in a Debian archive rebuild.
Revert all the way to the 2.69 behavior, which was to set LEXLIB to
-ll or -lfl if that library defines yywrap, but allow AC_PROG_LEX to
succeed if neither -ll nor -lfl exists on the system, even if a lex
program that doesn't define yywrap would need it.
(This behavior was a bug, but people have come to depend on it.
See https://savannah.gnu.org/support/index.php?110269 and the
thread starting from
https://lists.gnu.org/r/autoconf-patches/2020-07/msg00013.html
for gory details.)
To provide a path away from bug-compatibility, AC_PROG_LEX now takes
one argument, documented as a whitespace-separated list of options.
Two options are defined: ‘yywrap’ means to look for yywrap and behave
as if lex is unavailable if it isn’t found; ‘noyywrap’ means to not
look for yywrap at all. These are mutually exclusive.
Fixes bug #110346.
* lib/autoconf/programs.m4 (AC_PROG_LEX): Add an argument which
can be either ‘yywrap’, meaning to look for yywrap in -ll, or
‘noyywrap’, meaning to not look for yywrap at all. In the
absence of either option, issue an obsoletion warning and
revert to behavior bug-compatible with 2.69.
* tests/semantics.at: Add more tests of AC_PROG_LEX.
* tests/mktests.sh: Exclude AC_PROG_LEX from autogenerated tests.
* doc/autoconf.texi: Update documentation of AC_PROG_LEX.
* NEWS: Update notes on AC_PROG_LEX.
Some of the compiler options that AC_OPENMP tests, mean “enable
OpenMP” to one compiler, but “write output to a file named ‘mp’ or
‘penmp’” to other compilers. The author of AC_OPENMP believed that
this could only happen if compilation was *successful*, but didn’t
realize that one of the options means “write *preprocessed* output to
a file named ‘penmp’” to SunPRO C, and that this *would* succeed on
the test program. (AC_LINK_IFELSE fails anyway, because the
compilation didn’t create conftest$exeext.)
The option that actually means “enable OpenMP” to SunPRO C is earlier
in the list than the option that means “write preprocessed output to a
file named ‘penmp’”, so we might never have noticed this, but for a
second bug: if you have a bad combination of Solaris operating system
patches installed, it’s possible for this compiler to
successfully *compile* a program that uses OpenMP, but then fail
to *link* it because the OpenMP runtime library is out of sync with
the core C library. AC_OPENMP doesn’t distinguish this case from
“that option doesn’t mean ‘enable OpenMP’” so it goes on to other
entries in the list and hits the “write preprocessed output” one.
Implement four layers of defensive measures against this mess:
- Use an #error directive instead of a compile-time syntax error
to halt compilation when _OPENMP is not defined.
- For each option that might mean “enable OpenMP”, first do an
AC_COMPILE_IFELSE to find out whether it really means that, and
then an AC_LINK_IFELSE to find out whether it works. If the
compilation succeeds but the link fails, bail out of the loop and
declare OpenMP to be unsupported.
- If a file named ‘mp’ or ‘openmp’ exists in configure’s working
directory when AC_OPENMP begins, error out. This means it is safe
to delete any file named ‘mp’ or ‘openmp’ that exists at the *end*
of AC_OPENMP.
- If a file named ‘mp’ or ‘openmp’ exists in the top level of the
source tree with a configure.ac that uses AC_OPENMP, have autoconf
error out, too.
Fixes bug #110353. Problem reported by Dagobert Michelsen.
* lib/autoconf/c.m4 (_AC_LANG_OPENMP(C)): Change ‘choke me’ to
‘#error "OpenMP not supported"’.
(AC_OPENMP): AC_REQUIRE _AC_OPENMP_SAFE_WD. For each option, do
both a compile test and a link test; if the compile test succeeds
but the link fails, don’t go on to other candidate options.
Delete files named ‘mp’ and ‘penmp’ after the loop.
(_AC_OPENMP_SAFE_WD): New macro, subroutine of AC_OPENMP. If files
named ‘mp’ or ‘penmp’ exist, error out both at autoconf time and at
configure time.
* tests/torture.at (Files clobbered by AC_OPENMP): New test.
* doc/autoconf.texi: Document requirement not to have files
named ‘mp’ or ‘penmp’ next to a configure.ac that uses AC_OPENMP.
Zack Weinberg [Mon, 2 Nov 2020 16:00:38 +0000 (11:00 -0500)]
testsuite: Isolate aclocal from third-party macros (#110352).
Several tests in the testsuite run a system-provided aclocal, which
will look into its $prefix/share/aclocal for third-party macros.
If those macros are buggy, aclocal may bomb out even though the test
doesn’t use them, causing the test to fail spuriously.
In all tests that need to run aclocal, create an empty directory and
give aclocal the --system-acdir option pointing at that directory.
This masks out all these potentially buggy macros. (It does *not*
mask out AM_INIT_AUTOMAKE, which aclocal will find in a different
directory.)
In all tests that run autoreconf but *don’t* need to run aclocal,
create an empty aclocal.m4 and set ACLOCAL=true in the environment.
Fixes bug #110352. Problem reported by Dagobert Michelsen.
* tests/fortran.at
* tests/tools.at
* tests/torture.at:
Set ACLOCAL=true in the environment in all tests that run
autoreconf but don’t need to run aclocal.
Set ACLOCAL="aclocal --system-acdir <empty directory>" in all
tests that do need to run aclocal.
Zack Weinberg [Mon, 2 Nov 2020 01:04:19 +0000 (20:04 -0500)]
AC_LANG_CALL(C++): Use ‘int’ for return type of conftest::$2.
Commit 326c9a547423d25c621bc5c0ef76edbf6eda8c92 introduced a custom
AC_LANG_CALL for C++. Jani Välimaa reports in
https://lists.gnu.org/archive/html/bug-autoconf/2020-10/msg00054.html
that the new code does not handle AC_CHECK_LIB([foo], [main])
correctly. This is not the recommended way to use AC_CHECK_LIB, but
it’s what you get if you autoupdate from AC_HAVE_LIBRARY, and some
people may not have bothered replacing main with a more appropriate
symbol.
This patch changes the return type of the fake function declaration
for AC_CHECK_LIB’s second argument to be ‘int’, which is sufficient to
make g++ 10.2.0 happy again. We’re still on thin ice, unfortunately;
the code generated by AC_LANG_CALL *always* has undefined behavior, in
both C and C++, unless by chance the real prototype of the function
we’re probing for happens to match our fake declaration. The only
permanent cure is to stop faking declarations, and that’s going to be
a challenge.
* lib/autoconf/c.m4 (AC_LANG_CALL(C++)): Use ‘int’ for the return
type of the fake function declaration, to avoid problems when
the function whose declaration we’re faking is ‘main’.
Zack Weinberg [Mon, 2 Nov 2020 00:23:12 +0000 (19:23 -0500)]
Don’t search for X11 when cross compiling (#110345)
This is undesirable because X11 development headers and libraries
found by searching /usr are much more likely to belong to the build
operating system than the host operating system (being cross-compiled
for). A particularly problematic case, from the original bug report,
is “using a sysroot where the target is binary compatible with the
host. In this case AC_PATH_X will happily look at /usr and say that
yes, X is available, even if the sysroot doesn't have X.”
To cross-compile X client applications, the recommended procedure is
to put X11 headers and libraries for the host system in the cross
compiler’s default search path; alternatively, --x-includes and
--x-libraries can be used.
Fixes bug #110345. Problem reported by Ross Burton.
* lib/autoconf/libs.m4 (_AC_PATH_X): Before doing anything else,
see whether a test compilation with no special options (just -lX11)
will work. If it doesn’t, only invoke _AC_PATH_X_XMKMF and
_AC_PATH_X_DIRECT when not cross compiling.
Zack Weinberg [Sat, 31 Oct 2020 13:57:13 +0000 (09:57 -0400)]
Ignore stderr when testing parallel autotest (#110351).
Non-release versions of bash (notably 5.1.0(1)-rc1, which was uploaded
to Debian unstable) print internal debugging messages like
TRACE: pid 411364: bgp_delete: deleting 432074
to the test driver’s stderr while executing the parallel test driver.
This causes spurious failures in the test suite. Chet Ramsey assures
me these are not a symptom of a bug in either bash or the driver code
(see https://lists.gnu.org/archive/html/bug-autoconf/2020-10/msg00047.html)
so have the test suite ignore them.
This fixes Savannah bug #110351.
* tests/autotest.at: Ignore stderr whenever running a micro-suite in
parallel mode, to avoid spurious failures due to internal debugging
messages that may be printed by bash.
Zack Weinberg [Thu, 29 Oct 2020 13:21:52 +0000 (09:21 -0400)]
tests/m4sh.at: prevent an undesirable expansion of __oline__.
The descriptive comment for AT_DATA_LINENO mentions __oline__, and
this is expanded when generating the testsuite, which is confusing
to anyone reading the generated testuite. Defang it with @&t@.
* tests/m4sh.at (AT_DATA_LINENO): Prevent expansion of __oline__
in the descriptive comment.
Jannick [Wed, 28 Oct 2020 14:59:27 +0000 (10:59 -0400)]
Treat msys(2) the same as cygwin when looking at host_os.
In most cases, checks depending on the value of $host_os should
treat *-*-cygwin*, *-*-msys*, and *-*-mingw* all the same.
* lib/autoconf/fortran.m4 (_AC_FC_LIBRARY_LDFLAGS):
Discard -lkernel32 on msys* as well.
When not discarding -lkernel32, deduplicate it, like other -l options.
* lib/autoconf/functions.m4 (AC_FUNC_MALLOC, AC_FUNC_REALLOC):
msys* also guarantee to return nonnull for malloc(0)/realloc(0).
* tests/local.at (at_check_env): Also ignore MSYS as an environment
variable.
Zack Weinberg [Tue, 20 Oct 2020 17:36:58 +0000 (13:36 -0400)]
Improve handling of missing aux scripts (autoreconf)
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.
Zack Weinberg [Tue, 20 Oct 2020 17:27:22 +0000 (13:27 -0400)]
Improve handling of missing aux scripts.
Another regression identified by the Debian archive rebuild was that
more macros require the presence of config.sub and config.guess now.
‘autoreconf --install’ doesn’t install these itself, it relies on
‘automake --add-missing’ to do that; so, packages that don’t use
Automake will fail at the configure stage after configure is
regenerated. To make matters worse, AC_CONFIG_AUX_DIRS assumes that
everyone who needs config.sub and config.guess also needs install-sh,
so in about half of the affected packages, the failure manifested as a
complaint about install-sh being missing -- technically true but
adding install-sh wouldn’t have resolved the problem by itself.
This patch overhauls the AC_CONFIG_AUX_DIR(S) mechanism so that a
configure script knows the complete set of aux scripts that were
AC_REQUIRE_AUX_FILE’d for it, checks for the existence of all of
them, and not any others. Thus, this configure script
will work fine in a directory that contains config.sub and
config.guess but not install-sh. Also, if it’s in a directory
that *doesn’t* contain config.sub and config.guess, it will print an
accurate error message
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
A side-effect: it doesn’t make sense for AC_CONFIG_SUBDIRS to demand
the presence of Cygnus configure in the aux dir, on the off-chance
that one of the subdirectories *might* be using it -- I have no idea
where someone would even get a copy of that nowadays -- so I dropped
that feature. I rather suspect nobody has needed it in over a decade.
I also documented the expanded need for config.sub and config.guess in
NEWS as well as the manual.
* NEWS: Document expanded need for config.sub and config.guess.
Document removed support for Cygnus configure in subdirectories.
* doc/autoconf.texi: Clarify exactly when install-sh, config.sub,
and/or config.guess are required. Document canonical online sources
for these scripts. Revise documentation of AC_CONFIG_AUX_DIR and
AC_REQUIRE_AUX_FILE. Minor improvements to documentation of
AC_CONFIG_SRCDIR. Remove mentions of Cygnus configure in
subdirectories.
* lib/autoconf/general.m4
(_AC_INIT_PARSE_ARGS): Remove mention of Cygnus configure;
clarify function of configure.gnu.
(AC_CONFIG_AUX_DIR): Support multiple invocations.
(AC_CONFIG_AUX_DIRS): Now an undocumented compatibility interface
rather than an internal subroutine; just runs AC_CONFIG_AUX_DIR on
each of its arguments.
(AC_CONFIG_AUX_DIR_DEFAULT): Now a backward compatibility stub that
requires _AC_INIT_AUX_DIR without adding anything to _AC_AUX_FILES.
(AC_REQUIRE_AUX_FILE): Now adds the named aux file to _AC_AUX_FILES
and requires _AC_INIT_AUX_DIR, as well as being a trace hook.
(_AC_INIT_AUX_DIR): New home of the loop searching for necessary aux
files (formerly in AC_CONFIG_AUX_DIRS). Looks for all the necessary
aux files, not just for install-sh.
(ac_config_guess, ac_config_sub, ac_configure): Issue deprecation
warnings if these undocumented shell variables are actually used.
(AC_CANONICAL_BUILD, AC_CANONICAL_HOST, AC_CANONICAL_TARGET):
No need to require AC_CONFIG_AUX_DIR_DEFAULT.
Can rely on $ac_aux_dir ending with a slash.
* lib/autoconf/programs.m4 (AC_PROG_INSTALL, AC_PROG_MKDIR_P):
No need to require AC_CONFIG_AUX_DIR_DEFAULT.
* lib/autoconf/status.m4 (_AC_CONFIG_SUBDIRS):
No need to require AC_CONFIG_AUX_DIR_DEFAULT.
Remove check for Cygnus configure; clarify function of configure.gnu.
* lib/autotest/general.m4: Remove mention of Cygnus configure.
* tests/torture.at (Missing auxiliary files): New test.
Zack Weinberg [Thu, 15 Oct 2020 00:22:41 +0000 (20:22 -0400)]
autoreconf: cope with empty AC_CONFIG_SUBDIRS (bug 110331)
Commit 41edf99f9515f3f83398428c39d79e11266a5a0d 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.
Paul Eggert [Mon, 12 Oct 2020 06:53:41 +0000 (23:53 -0700)]
doc: improve AS_CASE, AS_IF doc
See the thread containing:
https://lists.gnu.org/r/bug-gnulib/2020-10/msg00033.html
* doc/autoconf.texi: Distinguish between Solaris 10 and later.
(Balancing Parentheses): Mention the Posix syntax for ‘case’,
typically a better solution nowadays.
(AS_CASE, AS_IF): Mention AC_REQUIRE, portability, parens.
(Prerequisite Macros): Tighten up example and make it less dated.
Say that AS_CASE and AS_IF are not needed outside macros.
* NEWS: Don’t mention AS_FOR. It’s not documented, and for
good reason since it is so ... quirky.
Zack Weinberg [Sat, 10 Oct 2020 18:07:53 +0000 (14:07 -0400)]
_AS_PATH_WALK: Use AS_IF for IF-NOT-FOUND argument.
The construct _AS_PATH_WALK was using to conditionally execute its
IF-NOT-FOUND argument, was a little too fragile: relatively natural
variations in usage, such as putting the final `])` on a line by
itself, could cause shell syntax errors. Use AS_IF instead.
* lib/m4sugar/m4sh.m4: Use AS_IF to execute IF-NOT-FOUND conditionally.
Zack Weinberg [Fri, 9 Oct 2020 13:02:47 +0000 (09:02 -0400)]
Fix regressions when using the C++ compiler to perform tests.
The Debian project has done an archive rebuild using autoconf 2.69c,
which found several serious regressions from 2.69 where test programs
used to be accepted by a C++ compiler, but are now rejected. Part of
the problem is that newer C++ compilers are more likely to reject
“traditional” sloppy C, but part of it is that bug fixes since 2.69
did not consider the possibility of test macros being used with
AC_LANG([C++]) in effect.
I’m still working on test suite improvements that will catch these
regressions in the future, but I don’t see any reason to delay the
actual bugfixes. (I’ve gotten far enough on the test suite changes
that I know they _will_ catch the bugs.)
* NEWS: Document that AC_FUNC_STRERROR_R no longer tries to detect a
strerror_r that exists in the C library but isn’t declared by string.h.
* lib/autoconf/c.m4
(AC_LANG_CALL(C++)): New macro. Use a more robust technique for
avoiding a type conflict with any intrinsic prototype.
(AC_LANG_CALL(C)): Remove #ifdef __cplusplus, this macro is no longer
used to generate C++ code.
* lib/autoconf/functions.m4
(AC_FUNC_CLOSEDIR_VOID): Rely on <dirent.h> to declare closedir.
Simplify test program. Use AC_COMPILE_IFELSE, not AC_RUN_IFELSE.
(_AC_FUNC_MALLOC_IF, _AC_FUNC_REALLOC_IF): Use void *, not char *,
for variable holding a value returned by malloc/realloc respectively.
(AC_FUNC_STRERROR_R): Don’t AC_CHECK_FUNCS_ONCE strerror_r.
AC_DEFINE HAVE_STRERROR_R if and only if we are also going to define
HAVE_DECL_STRERROR_R. Remove AC_RUN_IFELSE fallback when strerror_r
is not declared.
* lib/autoconf/headers.m4 (AC_USG): Use "", not 0, for the first
argument to rindex.
Zack Weinberg [Wed, 7 Oct 2020 13:01:16 +0000 (09:01 -0400)]
Don’t issue obsoletion warnings for AC_DIAGNOSE.
AC_DIAGNOSE is used in several extremely popular add-on macros,
notably AM_INIT_AUTOMAKE, AM_GNU_GETTEXT, and AC_LIBTOOL_DLOPEN.
Until newer versions of these macros are available, -Wobsolete
warnings for AC_DIAGNOSE will be unhelpful noise.
Therefore, make it so AC_DIAGNOSE(...) will still be replaced with
m4_warn(...) by autoupdate, but autoconf runs will not complain about
AC_DIAGNOSE. The bulk of the patch is augmenting AU_DEFUN so that it
can define a “silent” autoupdate replacement, and documenting the new
feature.
* lib/autoconf/autoupdate.m4 (AU_DEFUN): Add a fourth argument, SILENT,
which must be either empty or the word ‘silent’. If it is ‘silent’,
the macro being defined will *not* issue a -Wobsolete warning when
expanded by autoconf.
Tweak quotation to prevent emacs’ parenthesis matching from getting
confused.
(AU_ALIAS): Add the SILENT argument here as well.
* lib/autoconf/general.m4 (AC_DIAGNOSE): Define as a silent AU_DEFUN.
Add commentary explaining why this was done and when it can be
changed back.
* doc/autoconf.texi (AU_DEFUN, AU_ALIAS): Revise; document new SILENT
argument.
The changes are now classified into “backward incompatibilities”,
“new features”, “obsolete features and new warnings”,
“notable bug fixes”, and “autotest enhancements”.
Also make the warning about argument-quotation bugs more prominent
and explicit. (See for instance Savannah bug 110319.)
mktmpdir: Ensure that $tmp is always an absolute pathname.
Several autotools programs use ‘do’ to evaluate Perl code
generated into a file in the temporary directory created by
Autom4te::General::mktmpdir. If the environment variable
TMPDIR is a relative path, mktmpdir will set $tmp to a
relative path and we’ll end up trying to ‘do’ a relative
path, which searches for the file in @INC. This doesn’t
work under perl 5.26 or later, because ‘.’ was removed
from @INC in that version (for security reasons).
Ensure that mktmpdir sets $tmp to an absolute pathname.
Also use File::Temp::tempdir to create the temporary
directory, instead of shelling out to ‘mktemp -d’;
this eliminates a subprocess and means we don’t have
to worry about cleaning up the directory on exit.
Problem found by Kent Fredric and reported as
<https://bugs.gentoo.org/625576>.
Supersedes Gentoo’s autoconf-2.69-perl-5.26-2.patch.
* lib/Autom4te/General.pm
(mktmpdir): Use File::Temp to create temporary directory.
Ensure that $tmp is an absolute path.
(END): No need to clean up $tmp.
* tests/tools.at (autotools and relative TMPDIR): New test.
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 normally expands m4sugar macros as it
goes. Fortunately, the same workaround as is used for AC_FOREACH can
be applied. AC_OBSOLETE also needs that workaround, and cannot be
fully replaced automatically.
The bulk of the patch is removing internal uses of AC_DIAGNOSE.
* lib/autoconf/general.m4 (_AC_COMPUTE_INT): Define using AU_DEFUN.
(AC_DIAGNOSE, AC_FATAL, AC_WARNING): Autoupdate to m4_warn,
m4_fatal, and m4_warn([syntax], [$1]) respectively, using the same
paired AU_DEFUN/AC_DEFUN trick that is used for AC_FOREACH.
(AC_OBSOLETE): Autoupdate to m4_warn([obsolete], [$1]) and advise
hand-conversion to AU_DEFUN.
* lib/autoconf/autoupdate.m4 (AU_DEFUN): Tweak quoting so m4_warn([$3])
is emitted into the edited configure.ac instead of being expanded at
autoupdate time.
* tests/tools.at (autoupdating AC_FOREACH): Adjust grep expressions.
(autoupdating AC_DIAGNOSE and AC_WARNING): New test.
(autoupdating AC_FATAL): New test.
(autoupdating AC_OBSOLETE): New test.
* tests/mktests.sh (ac_exclude_list, au_exclude_list):
Exclude AC_DIAGNOSE, AC_FATAL, AC_FOREACH, AC_OBSOLETE, and AC_WARNING
if not already excluded.
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 refer to m4_warn for the list
of categories.
(m4_warn): Document the complete current list of categories.
(Reporting Messages): Delete section.
(AC_DIAGNOSE, AC_WARNING, AC_FATAL): Move to Obsolete Macros.
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 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.
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 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.
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 used yet, but will be in the next patch.
* lib/Autom4te/ChannelDefs.pm (merge_WARNINGS): New function.
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.
Jonathan Wakely [Tue, 22 Sep 2020 19:45:10 +0000 (15:45 -0400)]
doc: Fix cross-reference for AC_TRY_LINK
The documentation for AC_TRY_LINK has a cross-reference to "Running
the Compiler". This should be "Running the Linker" instead. Also
make the link in AC_TRY_LINK_FUNC consistent.
Commit 9b5c0f17741836e99d0a801c6309389d391c03f9 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.
Consistently use ‘our’ instead of ‘use vars’ in Perl.
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.
‘make fetch’ was updating several auxiliary files from the copy
embedded in Gnulib instead of from their official home. This patch
teaches fetch.pl to update as many as possible of them from their
official homes. The remaining exception is GNU license files, which,
except for fdl.texi, do not appear to have a public version control
system. Gnulib has a script for updating them, but it appears one
must be logged into some specific FSF-operated shell host for it to
work.
The files affected, and their official homes, are:
This change exposed a bug in fetch.sh: there is a subtle difference
between File::Spec->catpath and ->catfile and I should have been using
the latter.
* build-aux/fetch.pl: Can now fetch from arbitrary Savannah
repositories, not just from gnulib and automake. Fetch as
many files as possible from their official home, instead of
from gnulib. Use File::Spec->catfile, not ->catpath.
Strip trailing whitespace from all files.
Using HTTP::Tiny to talk to the network, instead of wget, means that
we can make just one TCP connection to git.savannah.gnu.org to do the
whole job, which is quite a bit faster. It should also be more
robust against weird characters in filenames / URLs and stuff.
The script has a higher requirement for Perl than is the standard in
autoconf -- 5.14 (first version with HTTP::Tiny), with IO::Socket::SSL
installed -- but that’s ok, I hope, because it’s maintainer-only and
not installed.
fetch.sh was the sole user of move-if-change, and the Perl script does
that job itself, but I left move-if-change in build-aux and on the fetch
list anyway, in case we discover another use for it in the future.
* build-aux/fetch.sh: Replace with...
* build-aux/fetch.pl: ... reimplementation in Perl.
* cfg.mk (fetch): Update to match.
All of the AC_PROG_*CPP macros fall back to ‘/lib/cpp’ if invoking the
relevant compiler with ‘-E’ doesn’t work. This is an obsolete
location to find the C preprocessor. Linux distributions tend to ship
a compatibility symlink, as do Solaris and AIX (as of the versions in the
GCC compile farm, anyway), but the BSDs no longer do.
The tests for this fallback are already expecting ‘cpp’ to be a
command findable via $PATH, so make the probe macros do the same
thing. (We still try ‘/lib/cpp’ if ‘cpp’ _isn’t_ in $PATH.)
* lib/autoconf/c.m4
(AC_PROG_CPP, AC_PROG_CXXCPP, AC_PROG_OBJCPP, AC_PROG_OBJCXXCPP):
If $CC / $CXX / $OBJC / $OBJCXX -E (respectively) does not run the
preprocessor, look for ‘cpp’ in $PATH before falling back to ‘/lib/cpp’.
* doc/autoconf.texi
(AC_PROG_CPP, AC_PROG_CXXCPP, AC_PROG_OBJCPP, AC_PROG_OBJCXXCPP):
Update to match.
Add Configure_ac.pm to set of files to be synced from automake.
This file seems to have been accidentally left off of the list of .pm
files that should be kept the same between automake and autom4te.
It’s already almost identical in both codebases.
It would make sense to sync ChannelDefs.pm too, but the copies of that
file in the two codebases have diverged; they would need to be
reconciled by hand first.
‘make fetch’ pulls the files maintained by Automake from gitweb, so we
always get the HEAD revision at the time of the operation. The files
maintained by Gnulib, on the other hand, are just copied from whatever
local gnulib checkout you happen to have on your hard drive at the
time, which might not have been updated recently and might not even be
checked out from gnulib trunk.
This patch makes us use the same logic for Gnulib that we do for
Automake. It also pulls all of the code out of cfg.mk to a separate
shell script. The lists of files to update from each repository are
also moved to that file.
* build-aux/fetch.sh: New script. Lists of files to fetch from
Gnulib and Automake are now kept here.
* cfg.mk (fetch): Run fetch.sh, it does all the work.
(gnulib-update, autom4te-update, WGETFLAGS, automake_gitweb)
(autom4te_files, move_if_change): Delete.
Zack Weinberg [Mon, 31 Aug 2020 15:37:19 +0000 (11:37 -0400)]
Fatalize all warnings in Perl code.
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.
Zack Weinberg [Mon, 31 Aug 2020 15:23:00 +0000 (11:23 -0400)]
Rationalize ‘use’ order in Perl code.
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.
Serhii Popovych [Wed, 10 Feb 2016 16:32:44 +0000 (16:32 +0000)]
perl: Replace -w option in shebangs with ‘use warnings’ in code
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.
Zack Weinberg [Fri, 28 Aug 2020 20:44:59 +0000 (16:44 -0400)]
BUGS: Remove mention of old shells lacking functions.
The change to require shell functions in configure scripts happened
circa 2009, well before the release of autoconf 2.69; if this was
causing problems for people we would have heard about it by now.
Zack Weinberg [Fri, 28 Aug 2020 20:42:28 +0000 (16:42 -0400)]
Fix testsuite failures from ‘make maintainer-check-c++’.
‘make maintainer-check-c++’ has two test failures that don’t show in
an ordinary ‘make check’. One of these is a pair of problems with the
semantics.at test of AC_CHECK_DECL(S):
* AC_CHECK_DECL cannot handle a function argument whose declared type
is ‘char []’; it generates a cast to the array type, which is
invalid in both C and C++. This was masked by an M4 quotation bug,
causing it to emit a cast to ‘char’ instead, prodicing code that
was valid C but invalid C++. I don’t think it’s practical to teach
AC_CHECK_DECL to do argument type decay, so I changed the type
signature in the AC_CHECK_DECL call (not in the actual declaration)
to ‘char *’. Conveniently this also avoids the quotation issue.
* In C++, apparently ‘extern struct { int x; } foo;’ is invalid.
(clang++ explains at length: “variable ‘foo’ is used but not
defined in this translation unit, and cannot be defined in any
other translation unit because its type does not have linkage.”)
Fixed by giving the struct a tag.
The other failure is an actual bug in AC_PROG_LEX: the test program
used by _AC_PROG_LEX_YYTEXT_DECL uses the flex utility function
‘input’, which is renamed to ‘yyinput’ when the scanner is compiled as
C++. Fixed with ifdefs in the offending action--it might seem cleaner
to use a macro defined in a %{ %} block, but that would be inserted into
the skeleton *above* the declaration of (yy)input, so I didn’t feel
it was safe.
* tests/semantics.at (AC_CHECK_DECLS): Adjust test programs for C++
compatibility and to work around lack of support for argument type
decay.
* programs.m4 (_AC_PROG_LEX_YYTEXT_DECL): Call yyinput(), not input(),
in scanner action when scanner is compiled as C++.
Zack Weinberg [Fri, 28 Aug 2020 17:59:05 +0000 (13:59 -0400)]
Suppress ‘make syntax-check’ complaint about use of strcmp.
Recently ‘make syntax-check’ added a lint rule discouraging use of
bare ‘strcmp’ (in favor of gnulib’s streq/strneq wrappers), which
triggers on some code in c.m4’s test for C++98 compliance.
This lint rule makes sense for typical C programs coded to GNU’s
standards, but not for autoconf’s test programs. There is no way to
disable it from outside the code, so this patch adds parentheses
around the name ‘strcmp’, which is sufficient to disable this
grep-based lint but doesn’t change the meaning of the code as
understood by an actual C++ compiler.
* c.m4 (_AC_CXX_CXX98_TEST_HEADER): Suppress ‘make syntax-check’
error on use of strcmp.
Zack Weinberg [Thu, 27 Aug 2020 14:14:53 +0000 (10:14 -0400)]
AS_INIT: ensure fds 0, 1, 2 are open
A patch was recently proposed for GNU libc to make *all* processes
start up with file descriptors 0, 1, and 2 guaranteed to be open.
Part of the rationale for this patch was that configure scripts fail
catastrophically if these fds are closed, even if you just want to run
--help or --version, e.g.
$ ./configure --version <&-; echo $?
./configure: line 555: 0: Bad file descriptor
1
configure scripts cannot rely on behavior specific to GNU libc, so
whether or not that patch gets committed, it makes sense for us to
make configure scripts robust against being started up with closed
stdin/stdout/stderr.
This patch adds code to ensure fds 0, 1, and 2 are open, early in
_AS_SHELL_SANITIZE. It uses a construct, ‘(exec 3>&n)’, that’s known
not to work in very old shells, but that’s OK because those shells
will be rejected by _AS_DETECT_BETTER_SHELL anyway. The worst-case
scenario is that the “This script requires a shell more modern than
all the shells I found on your system” error message won’t get printed.
When these fds are found not to be open, we open them on /dev/null, in
the normal I/O direction (0 for reading, 1 and 2 for writing). There
is a case for opening them in the *opposite* direction so that, for
instance, writes to fd 1 will fail when fd 1 started out closed.
However, that would expose latent bugs that I think should be dealt
with *after* 2.70. (See Savannah bug #110300 for more detail.)
I also took the opportunity to rationalize the order of operations in
_AS_SHELL_SANITIZE a little. All the special shell and environment
variables that we care about are dealt with immediately after
AS_BOURNE_COMPATIBLE, and _AS_PATH_SEPARATOR_PREPARE happens
immediately before the first use of _AS_PATH_WALK.
* lib/m4sugar/m4sh.m4 (_AS_ENSURE_STANDARD_FDS): New macro.
(_AS_SHELL_SANITIZE): Move the “Unset variables that we do not need”
and “NLS nuisances” blocks immediately after setting IFS; merge the
unsetting of CDPATH into the main unsetting loop; move invocation of
_AS_PATH_SEPARATOR_PREPARE to immediately above the “Find who we are”
block; invoke _AS_ENSURE_STANDARD_FDS immediately before
_AS_PATH_SEPARATOR_PREPARE.
* tests/base.at (configure with closed standard fds): New test.
* tests/torture.at (--help and --version in unwritable directory): New test.
Zack Weinberg [Wed, 26 Aug 2020 19:15:34 +0000 (15:15 -0400)]
Add ‘START_TIME’ and ‘ToD’ to shell variable filter list.
NetBSD sh has invented more magic shell variables with values related
to the current time: ‘START_TIME’ and ‘ToD’. Like ‘SECONDS’, these
can cause spurious testsuite failures and should be filtered out when
checking for undesirable changes to the environment.
* tests/local.at (_AT_CHECK_ENV, AT_CONFIG_CMP): Add shell variables
START_TIME and ToD to filter list.
Zack Weinberg [Wed, 26 Aug 2020 19:12:12 +0000 (15:12 -0400)]
Pass $(MAKE) down to testsuite.
If Make is not available under the command name ‘make’, only some
other name (e.g. ‘gmake’) then the test suite’s internal invocations
of Make will all fail unless you explicitly set MAKE=<the other name>
in the environment, which is obnoxious. Pass the value of $(MAKE)
down to the testsuite so that ‘gmake check’ Just Works.
Zack Weinberg [Fri, 21 Aug 2020 17:13:38 +0000 (13:13 -0400)]
Generate manpages directly from source code.
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.
Zack Weinberg [Fri, 21 Aug 2020 17:43:50 +0000 (13:43 -0400)]
Fix ‘make distcheck’ failure due to generated manpages in build dir.
If we are doing a VPATH build and we generate the manpages,
they will be written to the build directory, and should be
deleted by ‘make distclean’; ‘make distcheck’ fails if this
is not done. However, if we are doing a build in the source
directory, the manpages might have been shipped to us and we
should *not* delete them in ‘make distclean’.
* man/local.mk (distclean-local-man): New rule. Delete $(dist_man_MANS)
in VPATH builds only.
(MOSTLYCLEANFILES, .x.1): Don’t use globs to decide what to delete.
Zack Weinberg [Thu, 20 Aug 2020 15:04:20 +0000 (11:04 -0400)]
tests: New helper macro AT_CHECK_MAKE.
This macro factors out some repeated code surrounding tests that run
make, such as honoring $MAKE, *not* honoring $MAKEFLAGS, and
normalizing the exit status. Partially addresses bug #110267
(problems with Sun’s make barfing on GNU make options from
$MAKEFLAGS).
Also addresses some unrelated problems I noticed while changing all
the tests that run make to use this macro:
The shtool test is now properly skipped if shtool is not available on
the host system.
Some of the Fortran tests would create an executable and then run it,
others would create an executable and then the AT_CHECK operation that
would run it was commented out. There’s no evidence in the changelog
or the git history for why this was done. I uncommented all of the
commented-out cases; this can be undone easily if it causes
problems. (It can’t be an issue with cross-compilation because some
of the tests do run the executable.)
* tests/local.at (AT_CHECK_MAKE): New macro wrapping an AT_CHECK
invocation of make. All tests that run make updated to use this macro.
* tests/fortran.at: Uncomment all AT_CHECKs that run the just-compiled
program.
* tests/foreign.at (shtool): Skip the test if shtool is not available
from the host system. Simplify shell logic.
Zack Weinberg [Thu, 20 Aug 2020 17:13:04 +0000 (13:13 -0400)]
Properly skip erlang tests when erl/erlc are not available.
Fallout from the previous change, which I should’ve tested on a
machine without Erlang tools installed, before pushing.
It bugs me a little that we have to put these special exit codes into
autoconf itself instead of the testsuite, but it is what it is.
* lib/autoconf/erlang.m4 (AC_ERLANG_NEED_ERLC, AC_ERLANG_NEED_ERL):
Exit with code 77 on failure so testsuite understands to skip Erlang
tests in this case.
(AC_ERLANG_CHECK_LIB): Use AC_ERLANG_NEED_ERLC and AC_ERLANG_NEED_ERL
instead of the _PATH_ versions.
Zack Weinberg [Tue, 18 Aug 2020 20:47:42 +0000 (16:47 -0400)]
_AC_COMPILER_EXEEXT_CROSS: exit 77 if test program does not run
This causes our testsuite to report a skipped test, rather than a
failure, if the detected compiler for _AC_LANG produces broken
executables. It matches the behavior of _AC_COMPILER_EXEEXT_DEFAULT,
which has exited with that code for a long time if it hits the
“_AC_LANG compiler cannot *create* executables” failure case.
Partially addresses bug #110267. The Solaris 10 machine I have access
to, has a broken gccgo installation that generates executables that
crash on startup. Without this patch, test “358: Go” fails. With
this patch, it is skipped.
Zack Weinberg [Tue, 18 Aug 2020 19:46:02 +0000 (15:46 -0400)]
Generate manpages in build directory.
It is not necessary to generate the manpages in the source directory
during a split build; ‘make dist’ can still find them in the build
directory and put them in the tarball.
Also add some defensive logic to the .x.1 rule to ensure that
bin/command and tests/command exist before generating man/command.1.
Without this, if you do a sufficiently parallel build, help2man may
generate the manpage from an older installed copy of ‘command’.
(Ideally, we wouldn’t have to run ‘command’ at all and this would not
be an issue, but ‘help2man’ doesn’t appear to support that.)
After this patch, the only files written to the source directory
during the ‘make’ phase of a split build (starting from a clean Git
checkout) are
These are not under our control, they’re being created by automake’s
built-in rules for Texinfo documentation.
* man/local.mk: Replace all instances of $(mansrcdir) with literal ‘man’.
(.x.1): Ensure that bin/command, tests/command, and the man
directory exist before creating man/command.1.
Zack Weinberg [Tue, 18 Aug 2020 19:01:10 +0000 (15:01 -0400)]
Delete a dummy ChangeLog in ‘make distclean’.
‘make distcheck’ from git may create a dummy ChangeLog file in the
build directory. Delete this on ‘make distclean’, but don’t delete
a real ChangeLog (generated by the gen-ChangeLog rule).
* Makefile.am (distclean-local): Delete ChangeLog if it is the dummy
created to pacify automake.
Zack Weinberg [Tue, 18 Aug 2020 18:54:24 +0000 (14:54 -0400)]
Don’t distribute tests/ac*.at.
tests/ac*.at are generated files containing basic test cases for all
the public AC_* macros that can be invoked without arguments. They’re
generated using a simple awk script, and we already require awk at
build time because of automake, so there is no reason to ship them in
the tarball. If we don’t ship them in the tarball, we can simplify
the logic in tests/local.mk, and avoid writing these files to the
source directory in a split build.
This should fix a problem with split builds using Solaris’ dmake
(see bug #110289).
tests/mktests.sh probably doesn’t work right if any of its argument
paths have spaces in their names, but that’s a separate issue.
* tests/local.mk (tests/mktests.stamp): Don’t change directory or
rewrite the contents of $(AUTOCONF_FILES).
(TESTSUITE_GENERATED_AT): Remove $(srcdir) prefix.
Add tests/acerlang.at (accidentally omitted).
(CLEANFILES): Add $(TESTSUITE_GENERATED_AT), mktests.stamp and mktests.tmp.
(MAINTAINERCLEANFILES): Don’t set.
(EXTRA_DIST): Include only the hand-written .at files, $(TESTSUITE_HAND_AT).
* configure.ac: Run AC_PROG_AWK, if for some reason AM_INIT_AUTOMAKE
hasn’t done it for us.
* tests/mktests.sh: Use $AWK if set in environment. Shell script linting.
projects / thirdparty / autoconf.git / log
