summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* _AS_ENSURE_STANDARD_FDS: use lsof and fstat when possiblezack/ensure-standard-fdsZack Weinberg2020-08-271-9/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This follow-up patch adds additional ways of detecting whether fds 0, 1, 2 are closed, using the ‘lsof’ and ‘fstat’ utilities. The former is not a standard component of any OS, but is very widely installed and can produce machine-parseable output; the latter ships with many BSD variants but its output is in a fixed format not designed for machine parsing. Both of them may fail due to privilege restrictions. The biggest problem with using these is that we have to run a program and inspect its output. I tried capturing the output using command substitution, but that is often implemented using a pipe from the child process to the parent shell; if fd 0 (for instance) started out closed in the parent, the pipe is likely to occupy that fd number right when lsof/fstat is inspecting the parent’s file table, causing a false report that fd 0 is open. The only alternatives I am aware of are temporary files or named pipes, both of which involve creating directory entries somewhere...and we can’t assume we have mktemp(1). This patch uses a file in the current working directory, but that breaks all of the tests that assume ‘configure --help’ will not write to the current working directory (which seems like a reasonable promise for us to make, tbh). Better ideas solicited. * lib/m4sugar/m4sh.m4 (_AS_ENSURE_STANDARD_FDS): If /proc/<pid>/fdinfo is not available, try to use lsof or fstat.
* AS_INIT: try to ensure fds 0, 1, 2 are openZack Weinberg2020-08-273-21/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Obviously configure scripts cannot rely on behavior specific to GNU libc, so even if that patch gets committed, it might make sense for us to try to make configure scripts robust against being started up with closed stdin/stdout/stderr. This patch is a first attempt at adding this robustness. Detecting whether an fd is closed, readable, writable, or both, is trivial in C. In shell, on the other hand, I have not been able to find a technique that works to my satisfaction on a broad variety of Unixes. This patch uses /proc/<pid>/fdinfo when available (only on Linux, AFAIK). Otherwise, it relies on ‘exec 3>&n’, which can only detect whether an fd is *open*, not whether it is readable or writable. Worse, in some old shells (e.g. Solaris 10 /bin/sh) this construct will succeed regardless of whether fd ‘n’ is closed. (A questionably reliable old beard on Stack Overflow told me that this is a known bug in “the” Bourne shell, by which he presumably means the original implementation.) The second patch in this set adds logic to try using the ‘lsof’ and/or ‘fstat’ commands when available, which helps, but brings other problems and is possibly not worth the hassle. I’m asking for feedback on the code, suggestions for additional techniques to try, and opinions whether this is worth trying to do at all. The patchset is available as the ‘zack/ensure-standard-fds’ branch in git, if anyone would like to experiment with it. I’ve gotten clean testsuite runs on Debian unstable, Solaris 10, NetBSD 9, and FreeBSD 11 (the latter two are somewhat unusual installations) except as noted in the second patch. * 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.
* Add ‘START_TIME’ and ‘ToD’ to shell variable filter list.Zack Weinberg2020-08-261-2/+6
| | | | | | | | | | NetBSD sh has invented more magic shell variables with values related to the current time: ‘START_TIME’ and ‘ToD’. Like ‘SECONDS’, these can cause spurious testsuite failures and should be filtered out when checking for undesirable changes to the environment. * tests/local.at (_AT_CHECK_ENV, AT_CONFIG_CMP): Add shell variables START_TIME and ToD to filter list.
* Pass $(MAKE) down to testsuite.Zack Weinberg2020-08-261-1/+1
| | | | | | | | | | If Make is not available under the command name ‘make’, only some other name (e.g. ‘gmake’) then the test suite’s internal invocations of Make will all fail unless you explicitly set MAKE=<the other name> in the environment, which is obnoxious. Pass the value of $(MAKE) down to the testsuite so that ‘gmake check’ Just Works. * tests/local.mk (run_testsuite): Append MAKE=$(MAKE).
* Add NetBSD /bin/sh to the -n whitelist.Zack Weinberg2020-08-261-3/+4
| | | | | | | | | NetBSD’s /bin/sh sets a special variable “NETBSD_SHELL” to identify itself. This means we can whitelist it as not having a buggy -n implementation. * configure.ac: Assume -n mode works in shells that have a preset variable named NETBSD_SHELL.
* * 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.
* Generate manpages directly from source code.Zack Weinberg2020-08-2115-53/+386
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We generate manpages for autoconf’s installed programs (autoconf, autoheader, etc.) using help2man, which runs each program in order to learn its --help output. Each manpage therefore has a dependency on the existence of the corresponding program, but this dependency is intentionally left out of the Makefile so that one can build from a tarball release (which will include prebuilt manpages) without having help2man installed. But when building from a git checkout with high levels of parallelism (-j20 or so), the missing dependency can lead to build failures, because help2man will try to run the program before it exists. In an earlier patch I tried to work around this with a recursive make invocation in the ‘.x.1’ rule, to ensure the existence of the program. That only traded one concurrency bug for another, now we could have two jobs trying to build the same program simultaneously and they would clobber each other’s work and the build would still fail. Instead, this patch introduces a utility script ‘help-extract.pl’ that reads --help and --version information directly from the source code for each program. This utility, wrapped appropriately for each program, is what help2man now runs. Usage is a little weird because help2man doesn’t let you specify any arguments to the “executable” that it runs, but it works, and lets us write all of the true dependencies of each manpage into the Makefile without naming any file that would be created during a build from a tarball. help-extract.pl is a Perl script, so it introduces no new build-time requirements. A downside is that we have to make sure each of the script sources in bin/, and also part of lib/Autom4te/ChannelDefs.pm, are parseable by help-extract. The most important constraints are that the text output by --help must be defined in a global variable named ‘help’, and its definition has to be formatted just the way these definitions are currently formatted. Similarly for --version. Furthermore, only some non-literal substitutions are possible in these texts; each has to be explicitly supported in help-extract.pl. The current list of supported substitutions is $0, @PACKAGE_NAME@, @VERSION@, @RELEASE_YEAR@, and Autom4te::ChannelDefs::usage. The generated manpages themselves are character-for-character identical before and after this patch. * build-aux/help-extract.pl: New build script that extracts --help and --version output from manpages. * man/autoconf.w, man/autoheader.w, man/autom4te.w, man/autoreconf.w * man/autoscan.w, man/autoupdate.w, man/ifnames.w: New shell scripts which wrap build-aux/help-extract.pl. * man/local.mk: Generate each manpage by running help2man on the corresponding .w script, not on the built utility itself. Revise all dependencies to match. * bin/autoconf.as: Rename ‘usage’ variable to ‘help’ and ‘help’ variable to ‘usage_err’. * bin/autoheader.in: Call Autom4te::ChannelDefs::usage with no function-call parentheses, matching all the other scripts. * bin/autom4te.in: Initialize $version with a regular double-quoted string, not a heredoc, matching all the other scripts. * bin/autoscan.in: Remove global variable $configure_scan.
* Fix ‘make distcheck’ failure due to generated manpages in build dir.Zack Weinberg2020-08-211-3/+12
| | | | | | | | | | | | | | | If we are doing a VPATH build and we generate the manpages, they will be written to the build directory, and should be deleted by ‘make distclean’; ‘make distcheck’ fails if this is not done. However, if we are doing a build in the source directory, the manpages might have been shipped to us and we should *not* delete them in ‘make distclean’. Correction to 5d3c99e56247d5a6496729931774cff08cf8dc0f. * man/local.mk (distclean-local-man): New rule. Delete $(dist_man_MANS) in VPATH builds only. (MOSTLYCLEANFILES, .x.1): Don’t use globs to decide what to delete.
* tests: New helper macro AT_CHECK_MAKE.Zack Weinberg2020-08-206-96/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This macro factors out some repeated code surrounding tests that run make, such as honoring $MAKE, *not* honoring $MAKEFLAGS, and normalizing the exit status. Partially addresses bug #110267 (problems with Sun’s make barfing on GNU make options from $MAKEFLAGS). Also addresses some unrelated problems I noticed while changing all the tests that run make to use this macro: The shtool test is now properly skipped if shtool is not available on the host system. Some of the Fortran tests would create an executable and then run it, others would create an executable and then the AT_CHECK operation that would run it was commented out. There’s no evidence in the changelog or the git history for why this was done. I uncommented all of the commented-out cases; this can be undone easily if it causes problems. (It can’t be an issue with cross-compilation because some of the tests do run the executable.) * tests/local.at (AT_CHECK_MAKE): New macro wrapping an AT_CHECK invocation of make. All tests that run make updated to use this macro. * tests/fortran.at: Uncomment all AT_CHECKs that run the just-compiled program. * tests/foreign.at (shtool): Skip the test if shtool is not available from the host system. Simplify shell logic.
* 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.
* tests/suite.at: m4_include acerlang.at.Zack Weinberg2020-08-201-0/+1
| | | | | This corrects a long-standing oversight; the “blind” tests for the Erlang macros have never actually gotten run.
* _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.
* Generate manpages in build directory.Zack Weinberg2020-08-181-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 doc/version.texi doc/stamp-vti doc/autoconf.info doc/standards.info 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.
* Delete a dummy ChangeLog in ‘make distclean’.Zack Weinberg2020-08-181-0/+6
| | | | | | | | | ‘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.
* Don’t distribute tests/ac*.at.Zack Weinberg2020-08-183-41/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* autoreconf: mention intltoolize and gtkdocize in --help output.Zack Weinberg2020-08-181-5/+6
|
* autoreconf: integrate intltoolize into the standard configuration toolsEli Schwartz2020-08-184-23/+50
| | | | | | | 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-184-7/+36
| | | | | | | | | | 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-1815-34/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-184-31/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Avoid one-argument ‘main’Paul Eggert2020-08-061-2/+2
| | | | | | * tests/autotest.at (C unit tests, C unit tests (EXEEXT)): Avoid ‘int main (int argc)’ as the C standard says this is not portable.
* 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
|
* * TODO: Add -Werror support.Paul Eggert2020-08-061-0/+7
|
* AT_CHECK_MACRO: Preserve config.log and config.status from run 1.Zack Weinberg2020-08-051-0/+2
| | | | | | | | | | | 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)Zack Weinberg2020-08-042-195/+167
| | | | | | | | | | | | | | | | | | | | | | | | | 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)Zack Weinberg2020-08-041-7/+16
| | | | | | | | | | | | 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.
* Partially revert e54e3f90: restore use of $(MAKE) in error message.Zack Weinberg2020-08-041-1/+1
| | | | | | | 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.
* Expect OpenIndiana test failurePaul Eggert2020-08-021-0/+7
| | | | | | 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.
* 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.
* Fix regression: autotools and whitespace in file namesPaul Eggert2020-08-011-5/+1
| | | | | | * 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.
* make fetchPaul Eggert2020-08-012-3/+4
|
* Fix regression that broke Automake ‘make check’Paul Eggert2020-08-012-9/+30
| | | | | | | | | | | | | | | | | 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.
* * doc/autoconf.texi: Tweak wording.Paul Eggert2020-07-311-20/+20
|
* doc: Update some more macro descriptions.Bruno Haible2020-07-311-1/+6
| | | | | * doc/autoconf.texi (Particular Functions): Add a remark about AC_FUNC_MMAP. Clarify AC_FUNC_STRCOLL.
* doc: Refer to Gnulib where it makes sense.Bruno Haible2020-07-311-2/+29
| | | | | | | * 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.
* doc: Refer to Gnulib instead of asking clients to provide replacement code.Bruno Haible2020-07-311-0/+16
| | | | | | * 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.
* Remove obsolete Cray supportPaul Eggert2020-07-302-29/+5
| | | | | | | | | 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
* Simplify Makefiles embedded in autotest.atZack Weinberg2020-07-271-22/+4
| | | | | | | | | | | | | | | | | | | 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.)
* 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-202-3/+4
| | | | | | | | 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.
* Prefer ‘$(MAKE)’ to ‘make’ in MakefilesPaul Eggert2020-07-202-2/+2
| | | | | | * GNUmakefile (abort-due-to-no-makefile): * Makefile.am (check-coverage-report): Prefer ‘$(MAKE)’ to ‘make’ in diagnostics.
* 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-174-7/+15
| | | | | | | | * 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.
* Document that VAL must be a word in ${VAR-VALUE}Paul Eggert2020-07-161-19/+30
| | | | | | * doc/autoconf.texi (Shell Substitutions): Document that in ${VAR-VALUE}, VALUE must be a shell word, and omit examples implying otherwise.
* tests/autotest.at: don’t use suffix rules to generate executablesZack Weinberg2020-07-161-6/+6
| | | | | | | | | | | | | | | 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. Partially addresses #110267.
* tests/local.at: improve sed portabilityZack Weinberg2020-07-161-1/+2
| | | | | | | | | | Solaris 10 /bin/sed does not support * after \( … \), only after subexpressions that match a _single character_. Partially addresses #110267. Problem reported by Dagobert Michelsen. * tests/local.at (AT_CHECK_M4): Do not use star after parenthesized subexpression in sed s/// commands.
* Revise documentation for AC_PROG_LEX.Zack Weinberg2020-07-163-38/+46
| | | | | | | | | | - 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.
View Lorry Controller Status