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.
Eli Schwartz [Sun, 17 Mar 2019 19:01:22 +0000 (15:01 -0400)]
autoreconf: integrate intltoolize into the standard configuration tools
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.
Eli Schwartz [Sun, 17 Mar 2019 19:01:21 +0000 (15:01 -0400)]
autoreconf: integrate gtkdocize into the standard reconfiguration tools
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.
Zack Weinberg [Fri, 14 Aug 2020 17:16:58 +0000 (13:16 -0400)]
Warn if AC_INIT or AC_OUTPUT are missing from configure.ac (#107986)
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.
Zack Weinberg [Thu, 6 Aug 2020 18:51:32 +0000 (14:51 -0400)]
Trim whitespace from arguments of AC_INIT (#107986)
Specifically, all five arguments, if present, are passed through
m4_normalize before doing anything else with them. For instance,
AC_INIT([ GNU Hello ], [1.0]) is now equivalent to
AC_INIT([GNU Hello], [1.0]).
As a consequence, newlines in the arguments to AC_INIT are now
converted to spaces and no longer trigger warnings.
Also, diagnose inappropriate contents of the fourth and fifth
arguments as well as the first three. The fifth argument should be
“usable as-is in single- and double-quoted strings and quoted and
unquoted here-docs,” like the first three. (This is the check
performed by _AC_INIT_LITERAL.) The fourth argument (TARNAME) is used
to construct filenames, so apply an even more stringent test, namely
AS_LITERAL_WORD_IF.
Suggested by David A. Wheeler, who submitted a patch, but I didn’t
wind up using any of his code.
* lib/autoconf/general.m4 (_AC_INIT_LITERAL): Not necessary to check
for newlines anymore.
(_AC_INIT_PACKAGE): Pass all five arguments through m4_normalize
before doing anything else with them. New warning: apply
_AC_INIT_LITERAL to fifth argument (URL). New warning: complain
if fourth argument (TARNAME) is not a literal word according to
AS_LITERAL_WORD_IF. Simplify a conditional by using m4_default.
* tests/base.at (AC_INIT with unusual version strings): Adjust to
match above changes, add more subtests.
Paul Eggert [Fri, 7 Aug 2020 00:37:42 +0000 (17:37 -0700)]
Pacify -Werror in two places
Although this cannot easily be done in general, there are a couple
of places where it’s easy.
* lib/autoconf/c.m4 (AC_LANG_INT_SAVE (C)):
Change ‘()’ to ‘(void)’ to pacify picky compilers.
Problem reported by Vincent Lefevre in:
https://lists.gnu.org/r/autoconf-patches/2020-08/msg00000.html
(AC_C_INLINE): Likewise.
Zack Weinberg [Wed, 5 Aug 2020 14:45:22 +0000 (10:45 -0400)]
AT_CHECK_MACRO: Preserve config.log and config.status from run 1.
AT_CHECK_MACRO runs a test configure script twice and looks for
differences in the results. If something goes wrong, it’ll be helpful
for debugging to preserve the config.log and config.status files from
both runs.
* tests/local.at (AT_CHECK_MACRO): Also copy config.log and
config.status to config-log.$at_run and config-status.$at_run
respectively.
Only probe C++ language features, not library, for speed (#110285)
The test programs used by _AC_PROG_CXX_CXX98 and _AC_PROG_CXX_CXX11
can take several seconds to compile, even on current-generation CPUs.
Each of them may be test-compiled up to six times as the configure
script searches for appropriate command-line switches. This is
reported to cancel out all of the other performance gains made since
2.69.
Replace these programs with simpler ones that do not exercise the C++
standard *library* and can be compiled in less than a second each.
On my computer, which is quite new, the minimal configure script
AC_INIT
AC_PROG_CXX
executes in 4.5 seconds (wall-clock) before this change and 0.5
seconds after.
* lib/autoconf/c.m4 (_AC_CXX_CXX98_TEST_HEADER, _AC_CXX_CXX98_TEST_BODY):
Rewrite to test only C++ 1998 language features, not library features.
(_AC_CXX_CXX11_TEST_HEADER, _AC_CXX_CXX11_TEST_BODY):
Similarly for C++ 2011.
* doc/autoconf.texi (AC_PROG_CXX): Document this change.
Filter out _AST_FEATURES when comparing environment state. (#110283)
ksh93 uses an environment variable called _AST_FEATURES to communicate
with subshell instances of itself. Its value may change at any time
so AT_CHECK_ENV and AT_CONFIG_CMP should ignore it.
This was responsible for many spurious testsuite failures on
OpenIndiana. Problem reported by Bob Friesenhahn.
* tests/local.at (_AT_CHECK_ENV, AT_CONFIG_CMP): Add _AST_FEATURES to
list of variables set by shells to unstable values.
Zack Weinberg [Tue, 4 Aug 2020 12:46:59 +0000 (08:46 -0400)]
Partially revert e54e3f90: restore use of $(MAKE) in error message.
In commit 14d58bfd, the error message printed by the
‘abort-due-to-no-makefile’ rule in GNUmakefile was changed to refer to
the value of ‘$(MAKE)’ instead of a literal ‘make’. A subsequent
‘make fetch’ (e54e3f90) clobbered this. Put it back.
Paul Eggert [Sun, 2 Aug 2020 23:31:13 +0000 (16:31 -0700)]
Expect OpenIndiana test failure
On OpenIndiana, Perl file locking does not work atop NFS.
* tests/tools.at (autom4te cache locking):
Expect this test to file if Perl file locking does not work.
Paul Eggert [Sun, 2 Aug 2020 23:24:50 +0000 (16:24 -0700)]
Work around ksh93 bug that broke config.status
* lib/autoconf/status.m4 (_AC_OUTPUT_HEADER):
Use ‘>&1’, which is a no-op, to work around a bug in ksh93
Version JM 93t+ 2010-03-05 as used in OpenIndiana.
The bug causes ‘printf "foo"’ to mistakenly succeed in
some cases even though the underlying ‘write’ syscall fails.
The ‘>&1’ causes the printf to fail, as it should.
Paul Eggert [Sun, 2 Aug 2020 00:53:03 +0000 (17:53 -0700)]
Fix regression: autotools and whitespace in file names
* 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.
Paul Eggert [Sat, 1 Aug 2020 18:47:10 +0000 (11:47 -0700)]
Fix regression that broke Automake ‘make check’
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.
Bruno Haible [Fri, 31 Jul 2020 20:57:51 +0000 (13:57 -0700)]
doc: Refer to Gnulib where it makes sense.
* doc/autoconf.texi (Particular Functions): Point to Gnulib wherever Gnulib has
more workarounds than mentioned for the particular macro, namely for
AC_FUNC_CHOWN, AC_FUNC_FSEEKO, AC_FUNC_GETGROUPS, AC_FUNC_GETMNTENT,
AC_FUNC_MBRTOWC, AC_FUNC_STRERROR_R, AC_FUNC_STRTOLD.
Bruno Haible [Fri, 31 Jul 2020 20:57:37 +0000 (13:57 -0700)]
doc: Refer to Gnulib instead of asking clients to provide replacement code.
* doc/autoconf.texi (Particular Functions): Point to Gnulib for all macros that
may call AC_LIBOBJ, namely AC_FUNC_ALLOCA, AC_FUNC_MALLOC, AC_FUNC_OBSTACK,
AC_FUNC_REALLOC, AC_FUNC_STRNLEN.
Paul Eggert [Fri, 31 Jul 2020 01:51:14 +0000 (18:51 -0700)]
Remove obsolete Cray support
Gnulib removed this recently, and we should be consistent.
* doc/autoconf.texi (Autoheader Macros):
Use a more up-to-date example.
* lib/autoconf/functions.m4 (CRAY_STACKSEG_END): Remove.
This is backported from the following Gnulib patch:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=41a2d446c7984f8f39e3eeca40c6d30630969c10
This is a follow-up for the various patches to address problems with
tests 221 and 222 with various non-GNU make implementations. We’re
not trying to exercise Make at all in these tests; it’s just a
convenient way to invoke the compiler found by AC_PROG_CC on a test
program. The tests will be more reliable if we minimize the number of
Make features we are using. So: no implicit rules at all, and no
intermediates. Generate ‘testprog’ directly from ‘testprog.c’.
Also copy from fortran.at a more thorough set of substitution
variables for the compilation command, mainly for consistency,
and don’t use Makefile variables, again for consistency with
fortran.at.
(This is also, theoretically, faster since we’re only invoking the
compiler driver once, but it’s probably not enough of a difference to
measure.)
Paul Eggert [Wed, 22 Jul 2020 19:56:19 +0000 (12:56 -0700)]
Port AC_F77_LIBRARY_LDFLAGS to oneAPI HPC Toolkit
Problem reported by Bill Dieter in:
https://lists.gnu.org/r/bug-autoconf/2020-07/msg00089.html
* lib/autoconf/fortran.m4 (_AC_FC_LIBRARY_LDFLAGS):
Defend against ‘clang -mllvm -loopopt=0’.
Paul Eggert [Mon, 20 Jul 2020 22:10:33 +0000 (15:10 -0700)]
Don’t assume plain ‘make’ in C unit tests
Problem reported by Bruno Haible in:
https://savannah.gnu.org/support/?110273#comment6
* lib/autoconf/general.m4 (_AC_ARG_VAR_VALIDATE):
* tests/autotest.at (C unit tests, C unit tests (EXEEXT)):
Prefer ‘${MAKE-make}’ to ‘make’ in shell code.
Paul Eggert [Sat, 18 Jul 2020 01:42:26 +0000 (18:42 -0700)]
Port build procedure to AIX 7.1
* lib/freeze.mk (MY_AUTOM4TE, build_libdir, m4f_dependencies):
Prefer ‘$(top_build_prefix)’ to ‘$(top_builddir)/’.
The difference matters on AIX 7.1, where ‘make’ doesn’t know that
bin/autom4te and ./bin/autom4te are the same file,
and gets confused about dependencies without this change.
‘$(top_build_prefix)bin/autom4te’ expands to ‘bin/automake’
whereas ‘$(top_builddir)/bin/autom4te’ expands to
‘./bin/automake’, and the former works where the latter doesn’t.
Paul Eggert [Fri, 17 Jul 2020 22:06:49 +0000 (15:06 -0700)]
Test AC_FC_LINE_LENGTH only to 250 columns
* NEWS, doc/autoconf.texi, lib/autoconf/fortran.m4:
Document 250, not 254.
* tests/fortran.at (AC_FC_LINE_LENGTH): Test lines with 250
columns not 253, since Oracle Studio 12.6 Fortran 95 8.8
2017/05/30 goes up only to 250.
Paul Eggert [Fri, 17 Jul 2020 00:35:36 +0000 (17:35 -0700)]
Fix ${VAR-NONWORD} bugs
* lib/autoconf/functions.m4 (AC_FUNC_SELECT_ARGTYPES):
* lib/autoconf/programs.m4 (AC_FUNC_SELECT_ARGTYPES):
* lib/autotest/general.m4 (AT_INIT):
Rewrite to avoid ${VAR-VALUE} where VALUE is not a shell word.
tests/autotest.at: don’t use suffix rules to generate executables
In two tests, when @EXEEXT@ is empty, we were generating Makefiles
containing suffix rules with only one explicit suffix, e.g.
.o:
$(CC) -o $@ $^
Solaris 10’s ‘dmake’ does not understand this as a rule to create
‘foo’ from ‘foo.o’. That’s not the point of the tests, so use
ordinary per-rule commands to link the executables in these tests
instead.
Paul Eggert [Thu, 16 Jul 2020 16:46:28 +0000 (09:46 -0700)]
Fix AC_PROG_LEX regression
Problem reported by Ross Burton in:
https://savannah.gnu.org/support/?110269
* lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL):
If tests indicate that LEX or LEXLIB does not work, set LEX to ":"
and LEXLIB empty, instead of failing out of 'configure' entirely.
Bruno Haible [Wed, 15 Jul 2020 20:34:24 +0000 (22:34 +0200)]
doc: More clarifications regarding --host and --build.
* doc/autoconf.texi (Specifying Target Triplets): Describe the effects
of --host in more detail. Don't recommend to specify --build when
specifying --host. Add another example regarding MinGW.
Paul Eggert [Wed, 15 Jul 2020 20:29:29 +0000 (13:29 -0700)]
Revert mistaken patch for Bison
Problem reported by Bruno Haible in:
https://savannah.gnu.org/support/?110266
* lib/autoconf/programs.m4 (AC_PROG_YACC):
Go back to using bison -y instead of bison -o y.tab.c.
Paul Eggert [Wed, 15 Jul 2020 17:32:14 +0000 (10:32 -0700)]
Revert mistaken patch for Wine
* lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT_CROSS):
Revert patch trying to cater to GNU/Linux builds
for Wine. They should use --build as well as --host.
Problem reported by Bruno Haible in:
https://savannah.gnu.org/support/?110268
This macro was replaced by AC_CONFIG_HEADERS many years ago (before
the beginning of the VCS history) and isn’t even documented, but we
never got around to making autoupdate notice it. Problem reported
*in 2006* by jensseidel@users.sf.net.
There was one use of AC_CONFIG_HEADER in our source tree, which is
converted. Also, to avoid confusing people reading old NEWS or TODO
entries, all mentions of AC_CONFIG_HEADER therein are also replaced
with AC_CONFIG_HEADERS.
* lib/autoconf/status.m4 (AC_CONFIG_HEADER): Make an AU_ALIAS for
AC_CONFIG_HEADERS.
Add AC_PROG_EGREP to AU_DEFUN for AC_HEADER_STDC (#110215)
AC_HEADER_STDC used to use AC_EGREP_CPP, and therefore had the side
effect of AC_REQUIRE([AC_PROG_EGREP]). In 2.70 AC_HEADER_STDC is an
AU_DEFUN and, before this change, the replacement didn’t invoke
AC_PROG_EGREP, which broke configure scripts that assumed $EGREP would
be set. Problem reported by Ross Burton.
* lib/autoconf/headers.m4 (AU::AC_HEADER_STDC): Also invoke AC_PROG_EGREP.
Tom [Sun, 12 Jul 2020 14:44:11 +0000 (10:44 -0400)]
Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)
The search for the appropriate value for @LEXLIB@ did not distinguish
correctly between success (‘break’ out of a shell for loop, having set
$ac_cv_lib_lex) and failure (normal termination of the loop, value in
$ac_cv_lib_lex is garbage). Bug report and original patch by
Tom <tom@ojodeagua.com> with refinements by Zack Weinberg.
* lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL):
Error out if we cannot find the library that (f)lex scanners
need to be linked against, instead of continuing with @LEXLIB@
set to the empty string.
Update hyperlinks in the manual and README-hacking.
Lots of http:// -> https:// conversions;
refer to XZ Utils instead of the obsolete LZMA Utils;
remove dead link to dbaspot.com;
replace mention of -fmudflap with -fsanitize=
and add a proper cross-reference to the GCC manual for that.
Update links in COPYING, COPYINGv3, and COPYING.EXCEPTION.
- COPYINGv3 now exactly matches
https://www.gnu.org/licenses/gpl-3.0.txt
as of 2020-07-10.
The only change was to turn a bunch of http:// URLs
into https:// URLs.
- COPYING now exactly matches
https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
as of 2020-07-10
except that the FSF’s old postal address has been deleted
and <https://fsf.org/> inserted
(consistent with COPYINGv3).
Besides the above, the only change was to whitespace.
- A typo in a URL in COPYING.EXCEPTION was corrected.
Paul Eggert [Fri, 10 Jul 2020 20:42:26 +0000 (13:42 -0700)]
Document AS_IF(..., ..., [[]]) glitch
* doc/autoconf.texi (Common Shell Constructs):
Note the if-false arg problem reported by Jannick in:
https://lists.gnu.org/r/autoconf/2020-03/msg00045.html
Paul Eggert [Fri, 10 Jul 2020 19:03:44 +0000 (12:03 -0700)]
Fix ac_compiler_gnu bug
Problem and fix reported by Jannick in:
https://lists.gnu.org/r/autoconf/2020-03/msg00045.html
except that I omitted the comment, which I thought unnecessary.
* lib/autoconf/lang.m4 (_AC_LANG_COMPILER_GNU): Set
ac_compiler_gnu regardless of whether result was from cache.
Paul Eggert [Fri, 3 Jul 2020 05:23:59 +0000 (22:23 -0700)]
Fix AC_CHECK_LIB quoting bug
Problem reported by Bert Wesarg in:
https://lists.gnu.org/archive/html/autoconf/2016-04/msg00020.html
* lib/autoconf/libs.m4 (AC_CHECK_LIB): Fix quoting bug.
* tests/semantics.at (AC_CHECK_LIB): Add a test for the bug.
Zack Weinberg [Tue, 30 Jun 2020 02:13:23 +0000 (19:13 -0700)]
Consistently expand macros in whitespace-separated lists.
Several of the most commonly used Autoconf macros (starting with
AC_CHECK_FUNCS and AC_CHECK_HEADERS) take a whitespace-separated list
of symbols as their primary argument. It would abstractly be best if
this list were _not_ subject to M4 macro expansion, in case there’s a
collision between a M4 macro name and something to be looked for.
However, we have historically not been careful about this, and there’s
been reports of configure scripts using ‘dnl’ to write comments inside
the list. The AS_LITERAL_IF optimizations added to AC_CHECK_FUNCS and
AC_CHECK_HEADERS since 2.69 broke some of those scripts with bizarre
shell syntax errors.
Also, the macro expansion behavior is not consistent among all of the
macros that take whitespace-separated lists, nor is it consistent
between autoconf and autoheader.
Address this by introducing a new m4sugar macro, currently called
‘m4_validate_w’ (I’m open to suggestions for better names). Here’s
its documentation comment:
| m4_validate_w(STRING): Expands into m4_normalize(m4_expand([STRING])),
| but if that is not the same as just m4_normalize([STRING]),
| issue a warning.
The text of the warning is
| configure.ac:N: warning: whitespace-separated-list contains macros;
| configure.ac:N: in a future version of Autoconf they will not be expanded
If the unexpanded form of the string contains the token ‘dnl’ then
there’s an additional line:
| configure.ac:N: note: ‘dnl’ is a macro
All of the public macros that take a whitespace-separated list of
symbols are changed to pass that argument through m4_validate_w before
doing anything else with it, and the test suite is updated to verify
consistent behavior for every last one of them.
This addresses Savannah issues #110210 and #110211, and the harmless
but annoying autoheader behavior described at
https://lists.gnu.org/archive/html/bug-autoconf/2018-02/msg00005.html .
In order to avoid expanding relatively expensive m4sugar macros
multiple times per top-level macro invocation, several of the affected
Autoconf macros are restructured along the same lines as I did for
AC_REPLACE_FUNCS in the previous patch.
* lib/m4sugar/m4sugar.m4 (m4_validate_w): New macro.
* lib/autoconf/functions.m4 (AC_CHECK_FUNCS, AC_CHECK_FUNCS_ONCE)
(AC_REPLACE_FUNCS)
* lib/autoconf/general.m4 (AC_CONFIG_MACRO_DIRS, AC_CHECK_FILES)
* lib/autoconf/headers.m4 (AC_CHECK_HEADERS, AC_CHECK_HEADERS_ONCE)
* lib/autoconf/status.m4 (AC_CONFIG_SUBDIRS): Pass $1 through
m4_validate_w before use.
* lib/autoconf/headers.m4 (AC_CHECK_HEADERS): Refactor with helpers
_AC_CHECK_HEADERS_ONE_U, _AC_CHECK_HEADERS_ONE_S, _AC_CHECK_HEADERS_ONE_C.
(AC_CHECK_HEADERS_ONCE): Eliminate _AC_CHECK_HEADERS_ONCE.
(AC_CHECK_INCLUDES_DEFAULT): Don’t use _AC_CHECK_HEADERS_ONCE.
* lib/autoconf/functions.m4 (AC_CHECK_FUNCS): Refactor with helpers
_AC_CHECK_FUNCS_ONE_U, _AC_CHECK_FUNCS_ONE_S, _AC_CHECK_FUNCS_ONE_C.
* lib/autoconf/status.m4 (_AC_CONFIG_SUBDIRS): No need to use m4_normalize.
* tests/semantics.at: Add tests for expansion of M4 macros in
whitespace-separated list arguments to all of the above.
Zack Weinberg [Tue, 30 Jun 2020 01:55:39 +0000 (18:55 -0700)]
AC_REPLACE_FUNCS: invoke _AH_CHECK_FUNC and AC_LIBSOURCE unconditionally.
While investigating something else, I noticed that AC_REPLACE_FUNCS
calls _AH_CHECK_FUNC and AC_LIBSOURCE in the success branch of an
AC_CHECK_FUNC. This doesn’t work; both of those are marker macros
that need to be expanded unconditionally at m4 time so that traces
(placed by autoheader and automake, respectively) will fire. In order
to fix this while keeping the code readable, I would up doing a major
refactor. There are now four internal macros implementing AC_REPLACE_FUNCS.
_AC_REPLACE_FUNC_U is called unconditionally for every shell word in
the list passed to AC_REPLACE_FUNCS, and does _AH_CHECK_FUNC +
AC_LIBSOURCE if it can, or issues a warning if it can’t. (It could
make sense to make this a public function, if we think shell variables
in the AC_REPLACE_FUNCS list need to be supported long-term. I dunno
if there’s a use case that can’t be handled by AC_REPLACE_FUNCS inside
a shell conditional just as well.)
_AC_REPLACE_FUNC_L and _AC_REPLACE_FUNC_NL implement the actual test
performed for each function to be replaced; the difference is that _L
(for literal) can only be used on a function whose name is known at m4
expansion time, _NL (nonliteral) works regardless. _AC_REPLACE_FUNCS,
which already existed, handles looping either at m4 time or shell time
as appropriate. AC_REPLACE_FUNCS remains a thin wrapper that runs
_AC_REPLACE_FUNCS(m4_flatten([$1])).
The _bulk_ of the patch is changes to the testsuite so that it notices
the original bug. Specifically, AT_CHECK_AUTOHEADER now takes an
argument which is a whitespace-separated list of preprocessor macro
names that ought to appear in the generated config.h.in. This can be
set to ‘ignore’ to skip the test, and unfortunately that’s what the
“trivial” per-macro tests have to do (AT_CHECK_MACRO and friends), so
coverage is not ideal, but it’s better than what we had. Also,
AT_CHECK_M4 now normalizes the backtrace lines that appear in the
output of an AC_DIAGNOSE, e.g.
configure.ac:6: warning: The macro `AC_LANG_SAVE' is obsolete.
configure.ac:6: You should run autoupdate.
../../lib/autoconf/lang.m4:125: AC_LANG_SAVE is expanded from...
configure.ac:6: the top level
becomes
configure.ac:6: warning: The macro `AC_LANG_SAVE' is obsolete.
configure.ac:6: You should run autoupdate.
lang.m4: AC_LANG_SAVE is expanded from...
configure.ac:6: the top level
This allows us to write tests for these diagnostics that don’t depend
on the relationship between the source and build directories, and
won’t break when unrelated patches change the line number of a macro
definition.
* lib/autoconf/functions.m4 (AC_REPLACE_FUNCS, _AC_REPLACE_FUNCS)
(_AC_REPLACE_FUNC): Refactor into AC_REPLACE_FUNCS,
_AC_REPLACE_FUNCS, _AC_REPLACE_FUNC_U, _AC_REPLACE_FUNC_L,
_AC_REPLACE_FUNC_NL. Ensure that _AH_CHECK_FUNC and
AC_LIBSOURCE are invoked unconditionally at m4 expansion
time for each literal function name in the argument to
AC_CHECK_FUNCS. Issue warnings about non-literal names.
* tests/local.at (AT_CHECK_M4): Normalize backtrace lines from
the output of AC_DIAGNOSE / m4_warn.
(AT_CHECK_AUTOHEADER): Add arg EXPECTED-TMPLS
giving a list of preprocessor macro names that should appear
in the generated config.h.in. Use AT_CHECK_M4 to invoke autoheader.
(_AT_CHECK_AC_MACRO, AT_CHECK_MACRO, AT_CHECK_AU_MACRO):
Update uses of AT_CHECK_AUTOHEADER.
* tests/fortran.at, tests/semantics.at, tests/tools.at
* tests/torture.at: Update all uses of AT_CHECK_AUTOHEADER.
* tests/semantics.at (AC_REPLACE_FUNCS test): Make somewhat
more thorough, using new functionality of AT_CHECK_M4 and
AT_CHECK_AUTOHEADER.
Zack Weinberg [Tue, 30 Jun 2020 01:40:48 +0000 (18:40 -0700)]
Look harder for a shell whose -n is known to work.
The test suite was insisting on using /bin/sh -n for syntax checking,
which meant that if /bin/sh wasn’t one of the short list of shells
whose -n is known to work, we would skip all of the syntax-check
tests, even if some other shell was available that would work.
Instead do like _AS_DETECT_BETTER_SHELL, and loop over possible
shells, starting with $SHELL and going on to a hardwired list of
known-good possibilities. The result is written to the substitution
variable @SHELL_N@ and the testsuite uses that.
(Should we invoke AC_PATH_PROG on the result of the search if it’s not
already absolute?)
* configure.ac: Search for a shell whose -n mode is known to
work, instead of just checking /bin/sh. Set @SHELL_N@ to
what we find.
* tests/atlocal.in: Propagate @SHELL_N@ to testsuite.
* tests/local.at (AT_CHECK_SHELL_SYNTAX): Use $SHELL_N instead
of hardcoding /bin/sh. Update test for usable shell -n.
(AT_CHECK_AUTOCONF): Update test for usable shell -n.
* tests/tools.at: Update test for usable shell -n.
Paul Eggert [Mon, 29 Jun 2020 23:51:08 +0000 (16:51 -0700)]
Save and check Autom4te version in cache
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.
Paul Eggert [Mon, 29 Jun 2020 23:51:08 +0000 (16:51 -0700)]
Fix undefined behavior in AC_SYS_LARGEFILE
* lib/autoconf/specific.m4 (_AC_SYS_LARGEFILE_TEST_INCLUDES):
Avoid undefined behavior on platforms where off_t is 32 bits. See:
https://bugs.debian.org/742780
Andreas Barth [Mon, 29 Jun 2020 23:51:08 +0000 (16:51 -0700)]
Look for AM_PROG_LIBTOOL too
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
Zack Weinberg [Fri, 13 Mar 2020 18:50:50 +0000 (14:50 -0400)]
Define $as_echo and $as_echo_n for backward compatibility.
Commit 2b59b6f8a79b8bf77e178ff4e5aa0ede433d39cf removed the internal
shell variables $as_echo and $as_echo_n. It turns out that these are
used by several widely-used third-party m4 files (notably both
gnulib-common.m4 from gnulib, and ax_pthread.m4 from the Autoconf
macro archive) as well as any number of existing configure.ac’s.
Restore these shell variables, unconditionally defining them to use
printf. Issue -Wobsolete warnings if they are used, recommending the
use of AS_ECHO and AS_ECHO_N respectively. Add a test which checks
both that they do work and that they trigger warnings.
Zack Weinberg [Fri, 13 Mar 2020 17:38:46 +0000 (13:38 -0400)]
_AS_REEXEC_WITH_SHELL: don’t use AS_EXIT.
If _AS_REEXEC_WITH_SHELL fails to exec the selected “better” shell
interpreter, and that failure somehow doesn’t terminate the process,
it calls AS_EXIT([255]). This expands to an invocation of as_fn_exit.
However, the definition of as_fn_exit goes into the M4SH-INIT-FN
diversion, whereas _AS_REEXEC_WITH_SHELL goes into the M4SH-SANITIZE
diversion, so as_fn_exit won’t be defined at the point of this use.
We can’t move the definition of as_fn_exit earlier, because we don’t
know that the shell supports shell functions until after we get to the
end of the M4SH-SANITIZE diversion.
This is only a theoretical bug because, as the comments say, “all the
known shells bail out after a failed exec.” However, a shell that
doesn’t bail out will instead give the user a flood of nonsensical
error messages (starting with “as_fn_exit: not found” and then going
on to choke on the rest of the script) so I think we should fix it
anyway. There shouldn’t be any problem with using a plain ‘exit’ at
this point; no traps are active yet, and we are exiting with an
explicit error code.
Zack Weinberg [Fri, 13 Mar 2020 17:35:01 +0000 (13:35 -0400)]
README-hacking: re-configure from scratch during bootstrap.
When building autoconf from a git checkout, recommend running
‘make distclean’ and a second ‘./configure’ after regenerating
autoconf’s own configure script using the just-built autoconf.
If one only runs ‘make check’ at that point, some configure-time
tests will not be repeated using the new code, such as detection
of a “better” shell.
Paul Eggert [Fri, 13 Mar 2020 00:00:44 +0000 (17:00 -0700)]
Fix _AS_DETECT_BETTER_SHELL breakage
Problem reported by Zack Weinberg in:
https://lists.gnu.org/r/autoconf/2020-03/msg00017.html
* lib/m4sugar/m4sh.m4 (_AS_RUN): Use sh -c instead of
the no-longer-existent $as_echo. This fixes a bug introduced
in 2013-01-28T03:44:45Z!gary@gnu.org.
Zack Weinberg [Wed, 26 Feb 2020 15:27:38 +0000 (10:27 -0500)]
Fix `make syntax-check'.
There are two errors caught by make syntax-check currently.
First, the recent make update-copyright
(d78a7dd95fed24e417dfb4d08124a9ce7c1f7d1e) missed autoconf.texi, I
think because there are a bunch of .texi files in doc/ whose copyright
years should *not* be updated (e.g. standards.texi, fdl.texi) and the
exclusion pattern is too broad. I can't actually *find* the exclusion
pattern in the twisty maze of .mk files, all alike, so I just manually
updated autoconf.texi.
Second, it objects to an edit to an old section of NEWS. This is
because of d3dcd5895d64f6c86275c9333e2760a867e540e7, which is a
legitimate change (replacing http:// with https:// in a URL) so the
correct action is to change old_NEWS_hash to match.
Paul Eggert [Sat, 22 Feb 2020 01:17:45 +0000 (17:17 -0800)]
Remove definition of _DARWIN_USE_64_BIT_INODE
It’s not needed in currently-supported macOS versions, and was
problematic anyway in MacOS X 10.5 which was the only version that
could use it. Problem reported by Peter Eisentraut in:
https://lists.gnu.org/r/bug-autoconf/2020-02/msg00004.html
* lib/autoconf/specific.m4 (AC_SYS_LARGEFILE):
Don’t define _DARWIN_USE_64_BIT_INODE.
Paul Eggert [Sun, 6 Oct 2019 08:37:56 +0000 (01:37 -0700)]
Fix terminology typo in mkdir -p check
* lib/autoconf/programs.m4 (AC_PROG_MKDIR_P): Say “race-free”, not
“thread-safe”. Problem reported by Reuben Thomas in:
https://lists.gnu.org/r/bug-autoconf/2019-09/msg00003.html
Ondrej Dubaj [Wed, 28 Aug 2019 05:39:50 +0000 (07:39 +0200)]
Port tests to Bash 5
* tests/local.at (AT_CHECK_ENV, AT_CONFIG_CMP):
Add BASH_ARGC, BASH_ARGV to list of variables to be ignored when
comparing variable space dumps.
(AT_CONFIG_CMP): Also ignore LINENO.
* tests/m4sh.at: Also unset LINENO in 'reference' and 'test/test-1'.
Paul Eggert [Wed, 29 May 2019 20:00:26 +0000 (13:00 -0700)]
Port AC_C_BIGENDIAN to recent clang
Problem and trivial patch reported by Matthieu Gautier in:
https://lists.gnu.org/r/bug-autoconf/2019-05/msg00006.html
* lib/autoconf/c.m4 (AC_C_BIGENDIAN): Use unsigned short for
values greater than 2**15 - 1.
Noah Misch [Sun, 25 Nov 2018 04:57:43 +0000 (20:57 -0800)]
AC_CHECK_DECL: when cached, don't overwrite a werror flag
* lib/autoconf/general.m4 (_AC_CHECK_DECL_BODY): Restore werror flags
inside the AC_CACHE_CHECK that saves them. Commit 82ef7805faffa151e724aa76c245ec590d174580 broke this. From Tom Lane
(trivial change).
* tests/semantics.at (AC_CHECK_DECLS): Test this.
Paul Eggert [Tue, 20 Mar 2018 03:19:01 +0000 (20:19 -0700)]
lib: use list of unsafe chars, not safe ones
* lib/autoconf/general.m4 (_AC_INIT_CONFIG_LOG):
Rely on list of unsafe chars instead of list of safe ones.
This corresponds more closely to POSIX and should result
in less quoting.
* lib/autoconf/status.m4 (_AC_OUTPUT_CONFIG_STATUS):
Adjust to this change.
x
Paul Eggert [Sun, 29 Oct 2017 20:00:55 +0000 (13:00 -0700)]
lib: fix update_file timestamps
Problem reported by Bruno Haible in:
https://savannah.gnu.org/support/?109406
* lib/Autom4te/FileUtils.pm (update_file): Use rename + system
instead of move, since move truncates file timestamps.
Paul Eggert [Sat, 23 Sep 2017 18:21:04 +0000 (11:21 -0700)]
lib: check ‘install file dir/’
* lib/autoconf/programs.m4 (AC_PROG_INSTALL): Check that the
system install program works when the destination name has a
trailing slash. This helped catch problems in an experimental and
never-published version of GNU Coreutils, and is a good thing to
check in general.
Eric Blake [Wed, 25 Jan 2017 19:36:04 +0000 (13:36 -0600)]
doc: emphasize that config.h must be first
* doc/autoconf.texi (C and Posix Variants, System Services):
Remind user to include config.h first.
(Configuration Headers): Give another reason why config.h must be
first, and mention that only .c files need it.
Based on discussion on bugs.debian.org/158969
Eric Blake [Thu, 22 Dec 2016 23:16:08 +0000 (17:16 -0600)]
doc: Mention effect of 'autoreconf -fi' on INSTALL
Several projects have a bootstrap script that invokes
'autoreconf -fi' as part of a fresh version control checkout,
in order to avoid storing common files in version control,
while also allowing contributors to rerun bootstrap to pick
up the benefits of any upgrade of one of the autotools.
However, the documentation did not make it obvious that such
a setup will overwrite any customizations to files like
INSTALL, if those files are stored in version control, when
automake still considers that file to be standard based on
AM_INIT_AUTOMAKE settings. In such a case, a mere
'autoreconf -i' is good for the bootstrap script, while a
separate 'autoreconf -f' is good for picking up on an upgrade
of any autotools.
* bin/autoreconf.in (help): Mention standard files.
* doc/autoconf.texi (autoreconf Invocation): Add more text, including
warning that mixing --force and --install may undo customizations,
and that the set of files impacted is controlled by automake.
Reported by Emil Laine <laine.emil@gmail.com> Signed-off-by: Eric Blake <eblake@redhat.com>
projects / thirdparty / autoconf.git / log
