summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* fix ‘make syntax-check’ complaints (only affects comments).Zack Weinberg2020-11-033-3/+3
|
* _AC_PROG_YYTEXT_DECL: Forward declare yywrap (#110312)Jannick2020-11-031-0/+3
| | | | | | | | | | Some versions of lex need you to forward-declare yywrap in a %{ %} block before the rules section, if you’re going to define it yourself. May help with bug #110312. * lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL): In the test input to lex, forward-declare yywrap before the rules.
* Revert to 2.69-compatible behavior in AC_PROG_LEX (#110346)Zack Weinberg2020-11-021-18/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* AC_OPENMP: Avoid clobbering ‘mp’ and/or ‘penmp’ (#110353)Zack Weinberg2020-11-021-41/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* AC_LANG_CALL(C++): Use ‘int’ for return type of conftest::$2.Zack Weinberg2020-11-011-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | 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’.
* Don’t search for X11 when cross compiling (#110345)Zack Weinberg2020-11-011-12/+24
| | | | | | | | | | | | | | | | | | | | | | 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.
* Treat msys(2) the same as cygwin when looking at host_os.Jannick2020-10-282-4/+7
| | | | | | | | | | | | | | | 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.
* Improve handling of missing aux scripts (autoreconf)Zack Weinberg2020-10-202-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Improve handling of missing aux scripts.Zack Weinberg2020-10-204-76/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 AC_INIT([test], [1.0]) AC_FUNC_MALLOC AC_CONFIG_HEADERS([config.h]) AC_OUTPUT 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 required auxiliary files: config.guess config.sub instead of the misleading 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.
* _AS_PATH_WALK: Use AS_IF for IF-NOT-FOUND argument.Zack Weinberg2020-10-101-1/+1
| | | | | | | | | 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.
* Fix regressions when using the C++ compiler to perform tests.Zack Weinberg2020-10-103-45/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Don’t issue obsoletion warnings for AC_DIAGNOSE.Zack Weinberg2020-10-072-21/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* mktmpdir: Ensure that $tmp is always an absolute pathname.Zack Weinberg2020-09-241-24/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.Zack Weinberg2020-09-229-62/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/autoupdate.m4 * lib/autoconf/c.m4 * lib/autoconf/functions.m4 * lib/autoconf/general.m4 * lib/autoconf/headers.m4 * lib/autoconf/lang.m4 * lib/autoconf/status.m4 * lib/autoconf/types.m4 * tests/local.at * tests/tools.at: Use, and/or refer to, m4_warn instead 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.
* Disable all warnings when running autoconf as a subprocess.Zack Weinberg2020-09-221-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.Zack Weinberg2020-09-221-1/+64
| | | | | | | | | | | | | | | | 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.
* Manually sync ChannelDefs.pm from automake.Zack Weinberg2020-09-223-39/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Consistently use ‘our’ instead of ‘use vars’ in Perl.Zack Weinberg2020-09-213-26/+15
| | | | | | | | | | | | | | | | | | | 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 yet againZack Weinberg2020-09-215-51/+40
|
* AC_PROG_*CPP: Try ‘cpp’ before ‘/lib/cpp’Zack Weinberg2020-09-101-8/+8
| | | | | | | | | | | | | | | | | | | | | 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.
* make fetchZack Weinberg2020-09-034-4/+3
|
* Fatalize all warnings in Perl code.Zack Weinberg2020-08-318-8/+8
| | | | | | | | | | | | | | | | | | 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.
* Autom4te::XFile: Remove unnecessary imports.Zack Weinberg2020-08-311-4/+1
| | | | | | | | | | | | | Autom4te::XFile does not appear to have any use for Carp, DynaLoader, or File::Basename. This happened to catch my eye while I was doing the previous two patches. I have not done a comprehensive audit of imports in the Perl code. * lib/Autom4te/XFile.pm: Remove ‘use’s of Carp, DynaLoader, and File::Basename. (@ISA): Remove DynaLoader.
* Rationalize ‘use’ order in Perl code.Zack Weinberg2020-08-319-36/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* perl: Replace -w option in shebangs with ‘use warnings’ in codeSerhii Popovych2020-08-318-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some downstream redistributors for Autoconf wish to use ‘/usr/bin/env perl’ as the #! line for the installed Perl scripts. This does not work with command-line options on the #! line, as the kernel doesn’t support supplying more than one argument to a #! interpreter (this limitation is universal across Unixes that support #!, as far as I know). Remove ‘-w’ from all perl #! lines and instead add ‘use warnings’ to all the scripts and .pm files that didn’t already have it. This ‘use’ directive was added to Perl in version 5.6.0 (aka 5.006) so there is no change to our minimum Perl requirement. (It is necessary to add ‘use warnings’ to all the .pm files as well as the scripts, because the ‘-w’ command-line option turns on warnings globally, but ‘use warnings’ does so only for the current lexical scope.) Patch uplifted from OpenEmbedded, originally by Serhii Popovych. It’s a mechanical search-and-replace change so I do not believe a copyright assignment is necessary. * bin/autom4te.in, bin/autoreconf.in, bin/autoscan.in * bin/autoupdate.in, bin/ifnames.in: Remove -w from #! line and add ‘use warnings’ to imports. * lib/Autom4te/C4che.pm, lib/Autom4te/ChannelDefs.pm * lib/Autom4te/Channels.pm, lib/Autom4te/Configure_ac.pm * lib/Autom4te/FileUtils.pm, lib/Autom4te/General.pm * lib/Autom4te/Request.pm, lib/Autom4te/XFile.pm: Add ‘use warnings’ to imports.
* Fix testsuite failures from ‘make maintainer-check-c++’.Zack Weinberg2020-08-281-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ‘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++.
* Suppress ‘make syntax-check’ complaint about use of strcmp.Zack Weinberg2020-08-281-1/+3
| | | | | | | | | | | | | | | | 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.
* AS_INIT: ensure fds 0, 1, 2 are openZack Weinberg2020-08-281-26/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* * lib/autoconf/types.m4: Say "Microsoft" before "Windows".Paul Eggert2020-08-231-4/+4
|
* AC_TYPE_PID_T: Define pid_t correctly on 64-bit native Windows.Bruno Haible2020-08-231-1/+26
| | | | | | | Reported at <https://savannah.gnu.org/support/index.php?110296>. * lib/autoconf/types.m4 (AC_TYPE_PID_T): Define pid_t to '__int64' on 64-bit native Windows, and to 'int' otherwise.
* Properly skip erlang tests when erl/erlc are not available.Zack Weinberg2020-08-201-4/+4
| | | | | | | | | | | | | | 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.
* _AC_COMPILER_EXEEXT_CROSS: exit 77 if test program does not runZack Weinberg2020-08-181-1/+1
| | | | | | | | | | | | | 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.
* autoreconf: integrate intltoolize into the standard configuration toolsEli Schwartz2020-08-181-0/+1
| | | | | | | 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.
* autoreconf: integrate gtkdocize into the standard reconfiguration toolsEli Schwartz2020-08-181-0/+1
| | | | | | | | | | 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.
* Warn if AC_INIT or AC_OUTPUT are missing from configure.ac (#107986)Zack Weinberg2020-08-184-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Trim whitespace from arguments of AC_INIT (#107986)Zack Weinberg2020-08-181-22/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Pacify -Werror in two placesPaul Eggert2020-08-061-4/+4
| | | | | | | | | | 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.
* * lib/autoconf/c.m4: Bring XL C comments up to date.Paul Eggert2020-08-061-7/+7
|
* Only probe C++ language features, not library, for speed (#110285)Zack Weinberg2020-08-041-139/+108
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Work around ksh93 bug that broke config.statusPaul Eggert2020-08-021-2/+2
| | | | | | | | | * 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.
* make fetchPaul Eggert2020-08-011-2/+3
|
* Remove obsolete Cray supportPaul Eggert2020-07-301-20/+0
| | | | | | | | | 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
* Port AC_F77_LIBRARY_LDFLAGS to oneAPI HPC ToolkitPaul Eggert2020-07-221-0/+1
| | | | | | | 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’.
* Don’t assume plain ‘make’ in C unit testsPaul Eggert2020-07-201-1/+2
| | | | | | | | 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.
* Port build procedure to AIX 7.1Paul Eggert2020-07-171-4/+4
| | | | | | | | | | | * 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.
* Test AC_FC_LINE_LENGTH only to 250 columnsPaul Eggert2020-07-171-1/+1
| | | | | | | | * 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.
* Fix ${VAR-NONWORD} bugsPaul Eggert2020-07-163-10/+14
| | | | | | | * 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.
* Revise documentation for AC_PROG_LEX.Zack Weinberg2020-07-161-1/+1
| | | | | | | | | | - Better explanation of the additional tests performed by this macro, once the tool has been located. - Update advice re using Flex to generate a bundled lex.yy.c. - Remove text describing a bug in Automake that has long since been corrected.
* AC_PROG_LEX no longer sets LEXLIB for yywrapPaul Eggert2020-07-161-0/+5
| | | | | | | Suggested by Zack Weinberg in: https://lists.gnu.org/r/autoconf-patches/2020-07/msg00016.html * lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL): Define yywrap too.
* Fix AC_PROG_LEX regressionPaul Eggert2020-07-161-4/+9
| | | | | | | | 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.