Many existing projects have their own version.m4, and in some cases
having one is recommended by the Automake manual. As of 2.72, the
name collision causes a spurious warning about including ‘version.m4’
multiple times, because the “has this been included before” machinery
does not track full pathnames.
A proper fix is more complicated than anyone has time to develop;
let’s just rename our version.m4 to autoconf_version.m4, which should
be sufficiently distinctive.
Reported in <https://savannah.gnu.org/support/?111007>.
* lib/version.in: Rename to lib/autoconf_version.in.
* bootstrap, configure.ac, lib/freeze.mk, lib/local.mk,
lib/m4sugar/m4sugar.m4: Change all uses of version.m4 to
autoconf_version.m4, and all uses of version.in to
autoconf_version.in.
Follow-up on 416b8f50c9bd4e38f9bc48b946505d2a18f6b1fd.
* lib/autoconf/general.m4 (_AC_INIT_PREPARE): Emit function ac_exit_trap,
move remaining code from the 'trap 0' command to ac_exit_trap.
This patch adds support for the Algol 68 programming language to
Autoconf. It is based on the Algol 68 GCC front-end, which is
currently under development [1]. The front-end is temporarily hosted
in the sourceware forge until integration in GCC is completed [3].
Note that the GCC Algol 68 front-end is not yet integrated in the main
compiler, so it is developed and distributed off-tree. See
https://gcc.gnu.org/wiki/Algol68FrontEnd. Additional information
about the Algol 68 programming language, and how it is being evolved
by the GNU Algol 68 Working Group can be found at
https://algol68-lang.org.
Automake support for Algol 68 has been already pushed as of 2 February
2025.
[1] https://gcc.gnu.org/wiki/Algol68FrontEnd
[2] https://inbox.sourceware.org/gcc-patches/20250101020952.18404-1-jose.marchesi@oracle.com/T/#t
[3] https://forge.sourceforge.org/gcc/gcc-a68
Add support for the Algol68 programming language.
* lib/autoconf/a68.m4: New file.
* lib/autoconf/autoconf.m4: Include autoconf/a68.m4.
* lib/autoconf/Makefile.am (dist_autoconflib_DATA): Add a68.m4.
* lib/freeze.mk (autoconf_m4f_dependencies): Add
$(src_libdir)/autoconf/a68.m4.
* doc/autoconf.texi: Rebuild menus.
(Preset Output Variables): Mention Algol 68. Document A68FLAGS.
(Algol 68 Compiler): New subsection.
(Language Choice): Mention Algol 68.
(Generating Sources): Likewise.
(Running the Preprocessor): Likewise.
* tests/a68.at: New file.
* tests/suite.at: Include a68.at.
* tests/local.at (_AT_CHECK_ENV): Add A68 and A68FLAGS.
* NEWS: Update.
The current code fails with gcc r16-2729-g0d276cd378e and
-Werror=discarded-qualifiers -Werror=write-strings
(the -Werror=write-strings is useful to check compatibility of
user code with C++, and the -Werror=discarded-qualifiers is an
upgrade of a default warning to an error). Since this is a test
for C99, we may assume that const is supported by the compiler,
and adding const makes the code more robust in this context.
Copyright-paperwork-exempt: yes
* lib/autoconf/general.m4 (_AC_INIT_PREPARE): Emit functions ac_cache_dump,
ac_dump_debugging_info. In the trap command, invoke ac_dump_debugging_info.
(AC_CACHE_SAVE): Invoke ac_cache_dump instead of expanding _AC_CACHE_DUMP a
second time.
* lib/autoconf/general.m4 (_AC_UNDECLARED_BUILTIN):
Use shorter diagnostic, to be consistent with other changes.
(_AC_FUTURE_DARWIN): New macro.
(AC_CHECK_DECL): Require per-language _AC_FUTURE_DARWIN.
Use $ac_c_future_darwin_options alongside with
$ac_c_undeclared_builtin_options.
* NEWS: Mention the fix.
Co-authored-by: Paul Eggert <eggert@cs.ucla.edu>
* lib/autoconf/status.m4 (_AC_OUTPUT_FILES_PREPARE):
Use ‘sed -n '$='’ instead of ‘grep -c’, since these
are the only uses of grep in a minimal ‘configure’
and we are already using sed elsewhere.
Problem reported by Eric Blake in:
https://savannah.gnu.org/support/?111221
* lib/autoconf/general.m4 (_AC_DEFINE_UNQUOTED): Fix typo that
caused us to not use a here-document in some cases when we should.
* tests/torture.at (Substitute and define special characters):
Test for the bug.
It is needed when building Octave targeting Windows. Without it, the
implementation of "casin" from the Windows runtime is used instead of
the replacement from MinGW-w64. That means that results for the
"casin" function are wrong without that change.
* lib/autoconf/fortran.m4: Do not remove "-lmingwex" or "-lmoldname"
from the linker flags when targeting MinGW. Removing "-lmingwex" causes
an incorrect linker resolution for functions like "casin" for projects
that consist of Fortran and C++ sources. Removing "-lmoldname" causes
issues for Fortran projects that try to use POSIX-like C functions
without a '_' symbol prefix when targeting MinGW.
The only platform that had this problem was native Windows,
and MSVC's malloc sets errno since 2015 at least.
* lib/autoconf/functions.m4 (AC_FUNC_MALLOC): Guess yes when
cross-compiling.
* lib/autoconf/functions.m4 (_AC_FUNC_MALLOC_IF, _AC_FUNC_REALLOC_IF):
Add 3rd argument for cross-guessing; all callers changed.
Use ‘volatile’ so that compilers don’t second-guess.
Also guess yes on gnu*, midipix*, midnightbsd*.
Problem with AC_SUBST_FILE reported by Dylan Palauzov in:
https://lists.gnu.org/r/bug-autoconf/2024-10/msg00018.html
The other problems I found by a manual scan.
* bootstrap: Use printf, not echo.
* doc/autoconf.texi (Polymorphic Variables):
* lib/autoconf/fortran.m4 (_AC_PROG_FC_V_OUTPUT):
* lib/autoconf/general.m4 (_AC_CANONICAL_SPLIT):
* lib/autoconf/status.m4 (_AC_SUBST_FILES):
* lib/autotest/general.m4 (AT_FINISH):
Use AS_ECHO, not echo.
* lib/autoconf/general.m4 (_AC_INIT_PARSE_ARGS)
(_AC_ARG_VAR_VALIDATE):
Defend against ‘echo’ interpreting ‘\’ or leading ‘-’.
(_AC_EVAL, _AC_EVAL_STDERR): Add to comment yet another reason
that these macros are obsolete and should be removed. There’s no
point trying to change them as that’s more likely to hurt than
help the (zero?) callers who still use them.
* lib/autoconf/general.m4 (_AC_INIT_DEFAULTS, _AC_INIT_PREPARE):
* lib/autoconf/status.m4 (_AC_OUTPUT_FILES_PREPARE)
(_AC_OUTPUT_FILE, _AC_OUTPUT_HEADERS_PREPARE, AC_OUTPUT)
(_AC_OUTPUT_CONFIG_STATUS):
Work even if $CONFIG_STATUS contains shell metacharacters,
leading ‘-’, or no ‘/’.
* lib/autoconf/libs.m4 (_AC_PATH_X_XMKMF):
* lib/autoconf/programs.m4 (AC_PROG_MAKE_SET):
Allow more special characters in ‘make’ macros like LIBDIR and MAKE.
* lib/autoconf/headers.m4 (_AC_HEADERS_EXPANSION):
* lib/m4sugar/m4sh.m4 (AS_ECHO):
Go back to using '%s\n' instead of "%s\n".
(AS_VAR_GET): Work around the quoting problem by using printf
directly with "%s\\n" instead of AS_ECHO; this is safe now that we
assume printf.
Problem reported in <https://savannah.gnu.org/support/?111102>.
* lib/autotest/general.m4:
* lib/m4sugar/m4sh.m4 (_AS_REEXEC_WITH_SHELL):
* tests/wrapper.as:
Port to AIX 7.2 ksh93, whidh mishandles ${1+"$@"}, by not using
that construct.
Both the recursive and the iterative versions of m4_set_add_all had a
bug where they did not update the set size correctly if the set
contained tombstones. I guess m4_set_remove isn’t used that often.
(I found this bug by accident while investigating an unrelated thing.)
The root cause of the bug was that in the tombstone case we had two
different layers quarreling over who got the last word on the size of
the set: m4_set_add, called for each value argument, was updating the
set size for each actual addition, and then the outer expansion of
m4_set_add_all was clobbering those updates with a calculation based
on the number of times the loop evaluated to a ‘-’ character, which
in the tombstone case was always zero.
The fix is to not mess with the set size on each actual addition,
relying on the outer calculation in all cases. Most of the volume
of the patch is refactoring to eliminate all the duplicate copies of
the “add this element only if it isn’t already there” logic which were
confusing the issue.
I also made m4_set_add_all not go into an infinite loop if invoked
with fewer than two arguments. Possibly it should error out in this
case instead of silently doing nothing, but I don’t think it matters
very much.
* lib/m4sugar/m4sugar.m4 (_m4_set_add, _m4_set_add_clean):
New macros, factoring out common “add element to set” logic.
(m4_set_add): Redefine using _m4_set_add.
(_m4_set_add_all): Rename to _m4_set_add_all_clean; use _m4_set_add_clean.
(_m4_set_add_check): Use _m4_set_add, not m4_set_add; emit a string
of dashes as _m4_set_add_all_clean does.
(m4_set_add_all): Update to match renamed _m4_set_add_all_clean.
Do nothing if invoked with fewer than two arguments.
* lib/m4sugar/foreach.m4: Define variants of _m4_set_add_all_clean and
_m4_set_add_all_check, matching the behavior of the definitions in
m4sugar.m4. Do not define m4_set_add_all here.
* tests/m4sugar.at (m4_set): Add more tests of interaction among
m4_set_add_all, m4_set_remove, and m4_set_size.
The entire output of m4_joinall is supposed to be quoted, including
separators, but the foreach.m4 implementation (used with M4 1.4.x)
was missing some quotes, and we didn’t notice because the test suite
wasn’t thorough enough. Fix.
* lib/m4sugar/foreach.m4 (m4_joinall): Quote each separator as it’s
emitted.
* tests/m4sugar.at (m4_join test): Expand tests of both m4_join and
m4_joinall.
The shell variables $as_echo and $as_echo_n and the substitution
variables @ECHO_C@, @ECHO_N@, and @ECHO_T@ are implementation
details of the old implementation of AS_ECHO and AS_ECHO_N
(2.69-era; before the switch to use ‘printf’). We continue
to provide them for compatibility with various third-party macros and
Makefiles that used them, even though, as far as I can tell, they were
never documented. (Someone made ECHO_C etc. substitution variables on
purpose, though.)
For $as_echo and $as_echo_n, we can tell precisely when they are
needed, because all uses are exposed to M4 macro expansion.
Therefore, emit the necessary support code on first use and not
from AS_INIT. As a side effect this means the -Wobsolete warning
only appears on the first use of each, which IMHO is polite.
For @ECHO_C@, @ECHO_N@, and @ECHO_T@, we have no way of knowing
whether a substitution variable is used, but we *do* know that
substitution variables are exclusively a configure.ac thing, so their
support code can be moved to general.m4 and emitted from AC_INIT
rather than from AS_INIT.
(It’s faintly possible that someone decided to use $ECHO_C in an
Autotest script but considering how rare it is for people to use
Autotest at all, or any other non-Autoconf application of M4sh,
I think we can worry about that when we hear about it.)
* lib/m4sugar/m4sh.m4 (_AS_ECHO_N_PREPARE): Removed.
(AS_PREPARE, _AS_PREPARE): Don’t use _AS_ECHO_N_PREPARE.
(_as_echo_var_prepare, _as_echo_n_var_prepare): New macros which
emit the -Wobsolete warning and the support code for $as_echo and
$as_echo_n respectively.
(as_echo, as_echo_n): Move to bottom of the block that sets up
the current implementation of AS_ECHO. Invoke _as_echo_var_prepare
and _as_echo_n_var_prepare, respectively, on first use.
* lib/autoconf/general.m4 (_AC_INIT_ECHO_N): New internal macro,
contains the probe code that used to be in _AS_ECHO_N_PREPARE.
AC_SUBSTs ECHO_C, ECHO_N, and ECHO_T.
(AC_INIT): Don’t AC_SUBST ECHO_C, ECHO_N, and ECHO_T here.
Invoke _AC_INIT_ECHO_N.
This is useful for GNU Emacs, which still ports to that
old Android version. The change here is imported from Gnulib.
* lib/autoconf/functions.m4 (AC_FUNC_STRNLEN):
Also detect Android 5.0 bug. Use AC_COMPILE_IFELSE rather
than AC_CANONICAL_HOST for cross-compile test.
The recent glitch with C++11 underscores the fact that it’s
long past time for Autoconf to catch up with the C++ standards.
Add simple tests for each iteration of the C++ standard.
They can be improved later as needed. When testing for these
newer standards, do not also test for features required by earlier
standards, as this isn’t all that helpful, leads to an O(N**2)
growth of ‘configure’, and can result in problems such as the
C++11 vs C++20 bug recently fixed.
* lib/autoconf/c.m4 (_AC_CXX_CXX14_TEST_PROGRAM)
(_AC_CXX_CXX17_TEST_PROGRAM, _AC_CXX_CXX20_TEST_PROGRAM)
(_AC_CXX_CXX23_TEST_PROGRAM, _AC_CXX_CXX14_OPTIONS)
(_AC_CXX_CXX17_OPTIONS, _AC_CXX_CXX20_OPTIONS)
(_AC_CXX_CXX23_OPTIONS): New macros.
(_AC_C_C23_TEST_PROGRAM, _AC_C_C23_OPTIONS): New macros.
(_AC_PROG_CC_STDC_EDITION): Try C23 first.
(_AC_PROG_CXX_STDCXX_EDITION): Use them.
Trivial fix suggested by Peter Johansson in:
https://lists.gnu.org/r/autoconf/2024-05/msg00004.html
* lib/autoconf/c.m4 (_AC_CXX_CXX11_TEST_MAIN):
Do not test assigning u8"..." to char const *, as this
runs afoul of C++20.
As C23 is now mostly supported by GCC, it's time for
AC_PROG_CC to prefer C23 if available.
* lib/autoconf/c.m4 (_AC_C_C23_TEST_GLOBALS, _AC_C_C23_TEST_MAIN):
(_AC_C_C23_TEST_PROGRAM, _AC_C_C23_OPTIONS): New macros.
(_AC_PROG_CC_STDC_EDITION): Try C23 first.
Problems reported by Antonin Décimo in:
https://lists.gnu.org/r/autoconf/2024-04/msg00001.html
* lib/autoconf/c.m4 (_AC_C_C89_TEST_GLOBALS):
Do not test the value of __STDC__.
(_AC_C_C99_TEST_MAIN): Do not test for VLAs.
(_AC_C_C11_OPTIONS): Also test -std:c11.
