| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 2003, Joey Hess reported the following bug against Debian's
autoconf package (see http://bugs.debian.org/221483):
I noticed that if I ctrl-c autoconf, it can leave a partially
written, executable configure script. I was lucky enough to
get a configure script that exited with a shell parse error,
but if I had been unlucky, it might have exited 0 without
doing all the tests I expected it to do. That would have
sucked to ship to users.
There are many ways to update a file in a way that is not
prone to these problems, and I suggest that autoconf adopt
one of them.
Ben Pfaff wrote a patch to make autom4te replace the output file
atomically; Debian has carried it since 2006. He submitted it
to autoconf upstream in 2008 but it never went anywhere.
I (Zack) have dusted off the patch and made some minor improvements:
using File::Temp (with DIR set to the directory of the output file)
instead of a predictable temporary file name, and using
Autom4te::FileUtils::update_file instead of File::Copy::move.
I do not attempt to test the fix (the test would be inherently racey)
nor do I have autom4te delete the temp file if it crashes while the
file is being written (there is no way to do this with 100%
reliability and it strikes me as likely to cause more problems than it
solves).
Fixes our bug #110305.
* bin/autom4te.in (handle_output): When $output is to a regular or
nonexistent file, write to a temporary file in the same directory
and then rename it over $output after completion.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of the 2020-11-07 update, config.sub and config.guess
unconditionally use $(...) command substitution; see
<https://lists.gnu.org/archive/html/config-patches/2020-11/msg00011.html>.
Therefore, add this to the set of required shell features, searched
for by _AS_DETECT_BETTER_SHELL. On a system where /bin/sh doesn’t
support $(...), $CONFIG_SHELL will be set to one that does (and the
primary configure script will be re-executed using that shell).
AC_CANONICAL_* use $CONFIG_SHELL to execute config.guess/sub, so they
will keep working. This also means that configure scripts and
third-party macros that use $(...) will quietly start working
correctly on such ancient systems.
The test code is simple, but sufficient to weed out Solaris 10’s
/bin/sh, which doesn’t support $(...) but *does* support shell
functions.
I’m not going to touch any of the existing uses of `...` command
substitution in Autoconf proper for now, but it might make sense to
bulk upgrade them early in the 2.71 release cycle; if nothing else,
it would remove a major obstacle to running shellcheck over our
scripts.
* lib/m4sugar/m4sh.m4 (_AS_MODERN_CMDSUBST_WORKS): New macro.
(AS_INIT, AS_SHELL_SANITIZE): Call _AS_DETECT_REQUIRED for
_AS_MODERN_CMDSUBST_WORKS.
* NEWS: Mention the requirement for $(...).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As pointed out in sr #110368, since install-sh is now being installed
as part of autoconf, we should make sure to ship the latest version
rather than the version shipped by the automake that was used to
bootstrap the autoconf release tarball.
The build-aux/fetch.pl script is already supposed to fetch the latest
version, but install-sh is listed in .gitignore so any updates are
discarded when starting from a clean tree. Correct this.
At the same time, since mdate-sh is *not* installed by autoconf nor is
it directly referenced in any code maintained in the autoconf
repository, remove it from the list of files to fetch and keep it in
.gitignore.
This change exposed a bug in fetch.pl where it would crash when
there was no old copy of a file being updated.
* .gitignore: Remove /build-aux/install-sh.
* build-aux/fetch.pl (%to_fetch): Remove build-aux/mdate-sh.
(slurp): Don’t die on ENOENT, return undef.
(replace_if_change): Handle $oldcontents being undef.
* build-aux/install-sh: Is now checked in.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in https://github.com/gentoo/gentoo/pull/163, gettext 0.19.6
supports using AM_GNU_GETTEXT_REQUIRE_VERSION (specifying a *minimum*
required version of gettext) instead of AM_GNU_GETTEXT_VERSION
(which specifies a *fixed* required version of gettext).
Update autoreconf to support both.
* bin/autoreconf.in (autoreconf_current_directory): Check for
AM_GNU_GETTEXT_REQUIRE_VERSION as well as AM_GNU_GETTEXT_VERSION.
Update diagnostics about using AM_GNU_GETTEXT_VERSION but not
AM_GNU_GETTEXT, or vice versa, to match.
* doc/autoconf.texi (autoreconf Invocation): Update to match.
|
| |
|
|
|
|
|
|
|
|
| |
Found by exhaustive testing for differences between probe results
under AC_LANG(C) and AC_LANG(C++).
* lib/autoconf/c.m4 (AC_C_FLEXIBLE_ARRAY_MEMBER): Cast result of
malloc for C++ compatibility.
* lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL): Declare yywrap
as extern "C" when compiling as C++.
|
| |
|
|
|
|
|
|
|
| |
While testing the previous patch I noticed that the ‘forbidden tokens,
basic’ test can fail if it runs too fast, because the autom4te cache
files aren’t considered newer than configure.ac.
* tests/tools.at (forbidden tokens, basic): Add delays to ensure
autom4te.cache files are newer than configure.ac.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
autoreconf expects to find $(pkgdatadir)/build-aux/config.sub etc
under those names, not names modified by --program-transform-name.
Placing them in $(pkgdatadir) is sufficient to keep parallel
installations of autoconf separate: anyone doing that would need
to adjust @PACKAGE@ anyway.
* lib/local.mk: Use a _DATA rule, not a _SCRIPTS rule, to install
config.guess, config.sub, and install-sh.
(install-data-hook-make-aux-scripts-executable): New hook rule.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I misremembered how AC_LANG_PROGRAM works. We don’t need to invoke
AC_INCLUDES_DEFAULT here but we *do* need to explicitly include
string.h.
Unfortunately we have no good way of testing for this regression with
the testsuite as it is today.
* lib/autoconf/functions.m4 (AC_FUNC_STRERROR_R): Include string.h in
test program.
|
| |
|
|
|
|
|
|
|
| |
Some widely used Automake recipes involve putting AC_REQUIRE_AUX_FILE
at top level of a configure script, and it uses AC_REQUIRE now, so it
needs to be defined with AC_DEFUN.
* lib/autoconf/general.m4 (AC_REQUIRE_AUX_FILE): Define with AC_DEFUN.
* tests/torture.at (Missing auxiliary files (foreign)): New test.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
In very old perls (I noticed this with 5.8.4), File::Temp objects are
not automatically stringified in all contexts where we expect them to
be, causing autoreconf to crash.
* bin/autoreconf.in (install_aux_file): Explicitly extract the
temporary file’s name from $temp, and use that in all the places we
were using $temp.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 29ede6b96feee29c0c477d1659081bbdb82cd8b3 caused AC_PROG_LEX to
stop looking for a library that provides yywrap. This broke several
packages in a Debian archive rebuild.
Revert all the way to the 2.69 behavior, which was to set LEXLIB to
-ll or -lfl if that library defines yywrap, but allow AC_PROG_LEX to
succeed if neither -ll nor -lfl exists on the system, even if a lex
program that doesn't define yywrap would need it.
(This behavior was a bug, but people have come to depend on it.
See https://savannah.gnu.org/support/index.php?110269 and the
thread starting from
https://lists.gnu.org/r/autoconf-patches/2020-07/msg00013.html
for gory details.)
To provide a path away from bug-compatibility, AC_PROG_LEX now takes
one argument, documented as a whitespace-separated list of options.
Two options are defined: ‘yywrap’ means to look for yywrap and behave
as if lex is unavailable if it isn’t found; ‘noyywrap’ means to not
look for yywrap at all. These are mutually exclusive.
Fixes bug #110346.
* lib/autoconf/programs.m4 (AC_PROG_LEX): Add an argument which
can be either ‘yywrap’, meaning to look for yywrap in -ll, or
‘noyywrap’, meaning to not look for yywrap at all. In the
absence of either option, issue an obsoletion warning and
revert to behavior bug-compatible with 2.69.
* tests/semantics.at: Add more tests of AC_PROG_LEX.
* tests/mktests.sh: Exclude AC_PROG_LEX from autogenerated tests.
* doc/autoconf.texi: Update documentation of AC_PROG_LEX.
* NEWS: Update notes on AC_PROG_LEX.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the compiler options that AC_OPENMP tests, mean “enable
OpenMP” to one compiler, but “write output to a file named ‘mp’ or
‘penmp’” to other compilers. The author of AC_OPENMP believed that
this could only happen if compilation was *successful*, but didn’t
realize that one of the options means “write *preprocessed* output to
a file named ‘penmp’” to SunPRO C, and that this *would* succeed on
the test program. (AC_LINK_IFELSE fails anyway, because the
compilation didn’t create conftest$exeext.)
The option that actually means “enable OpenMP” to SunPRO C is earlier
in the list than the option that means “write preprocessed output to a
file named ‘penmp’”, so we might never have noticed this, but for a
second bug: if you have a bad combination of Solaris operating system
patches installed, it’s possible for this compiler to
successfully *compile* a program that uses OpenMP, but then fail
to *link* it because the OpenMP runtime library is out of sync with
the core C library. AC_OPENMP doesn’t distinguish this case from
“that option doesn’t mean ‘enable OpenMP’” so it goes on to other
entries in the list and hits the “write preprocessed output” one.
Implement four layers of defensive measures against this mess:
- Use an #error directive instead of a compile-time syntax error
to halt compilation when _OPENMP is not defined.
- For each option that might mean “enable OpenMP”, first do an
AC_COMPILE_IFELSE to find out whether it really means that, and
then an AC_LINK_IFELSE to find out whether it works. If the
compilation succeeds but the link fails, bail out of the loop and
declare OpenMP to be unsupported.
- If a file named ‘mp’ or ‘openmp’ exists in configure’s working
directory when AC_OPENMP begins, error out. This means it is safe
to delete any file named ‘mp’ or ‘openmp’ that exists at the *end*
of AC_OPENMP.
- If a file named ‘mp’ or ‘openmp’ exists in the top level of the
source tree with a configure.ac that uses AC_OPENMP, have autoconf
error out, too.
Fixes bug #110353. Problem reported by Dagobert Michelsen.
* lib/autoconf/c.m4 (_AC_LANG_OPENMP(C)): Change ‘choke me’ to
‘#error "OpenMP not supported"’.
(AC_OPENMP): AC_REQUIRE _AC_OPENMP_SAFE_WD. For each option, do
both a compile test and a link test; if the compile test succeeds
but the link fails, don’t go on to other candidate options.
Delete files named ‘mp’ and ‘penmp’ after the loop.
(_AC_OPENMP_SAFE_WD): New macro, subroutine of AC_OPENMP. If files
named ‘mp’ or ‘penmp’ exist, error out both at autoconf time and at
configure time.
* tests/torture.at (Files clobbered by AC_OPENMP): New test.
* doc/autoconf.texi: Document requirement not to have files
named ‘mp’ or ‘penmp’ next to a configure.ac that uses AC_OPENMP.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several tests in the testsuite run a system-provided aclocal, which
will look into its $prefix/share/aclocal for third-party macros.
If those macros are buggy, aclocal may bomb out even though the test
doesn’t use them, causing the test to fail spuriously.
In all tests that need to run aclocal, create an empty directory and
give aclocal the --system-acdir option pointing at that directory.
This masks out all these potentially buggy macros. (It does *not*
mask out AM_INIT_AUTOMAKE, which aclocal will find in a different
directory.)
In all tests that run autoreconf but *don’t* need to run aclocal,
create an empty aclocal.m4 and set ACLOCAL=true in the environment.
Fixes bug #110352. Problem reported by Dagobert Michelsen.
* tests/fortran.at
* tests/tools.at
* tests/torture.at:
Set ACLOCAL=true in the environment in all tests that run
autoreconf but don’t need to run aclocal.
Set ACLOCAL="aclocal --system-acdir <empty directory>" in all
tests that do need to run aclocal.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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’.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Non-release versions of bash (notably 5.1.0(1)-rc1, which was uploaded
to Debian unstable) print internal debugging messages like
TRACE: pid 411364: bgp_delete: deleting 432074
to the test driver’s stderr while executing the parallel test driver.
This causes spurious failures in the test suite. Chet Ramsey assures
me these are not a symptom of a bug in either bash or the driver code
(see https://lists.gnu.org/archive/html/bug-autoconf/2020-10/msg00047.html)
so have the test suite ignore them.
This fixes Savannah bug #110351.
* tests/autotest.at: Ignore stderr whenever running a micro-suite in
parallel mode, to avoid spurious failures due to internal debugging
messages that may be printed by bash.
|
| |
|
|
|
|
|
|
|
| |
The descriptive comment for AT_DATA_LINENO mentions __oline__, and
this is expanded when generating the testsuite, which is confusing
to anyone reading the generated testuite. Defang it with @&t@.
* tests/m4sh.at (AT_DATA_LINENO): Prevent expansion of __oline__
in the descriptive comment.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
xsystem_hint() executes the command, so there's no need to call xsystem()
afterwards.
* bin/autoreconf.in: No need to call xsystem($cmd) immediately after
calling xsystem_hint("message", $cmd).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 41edf99f9515f3f83398428c39d79e11266a5a0d made all Perl warnings
fatal. This caused autoreconf to crash on packages that call
AC_CONFIG_SUBDIRS with no arguments. They probably shouldn’t do that,
but we shouldn’t crash if they do.
Problem reported by Ross Burton.
* bin/autoreconf.in (autoreconf_current_directory):
Convert undef to '' before attempting to split it.
* tests/torture.at (Empty AC_CONFIG_SUBDIRS): New test.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
See the thread containing:
https://lists.gnu.org/r/bug-gnulib/2020-10/msg00033.html
* doc/autoconf.texi: Distinguish between Solaris 10 and later.
(Balancing Parentheses): Mention the Posix syntax for ‘case’,
typically a better solution nowadays.
(AS_CASE, AS_IF): Mention AC_REQUIRE, portability, parens.
(Prerequisite Macros): Tighten up example and make it less dated.
Say that AS_CASE and AS_IF are not needed outside macros.
* NEWS: Don’t mention AS_FOR. It’s not documented, and for
good reason since it is so ... quirky.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AC_DIAGNOSE is used in several extremely popular add-on macros,
notably AM_INIT_AUTOMAKE, AM_GNU_GETTEXT, and AC_LIBTOOL_DLOPEN.
Until newer versions of these macros are available, -Wobsolete
warnings for AC_DIAGNOSE will be unhelpful noise.
Therefore, make it so AC_DIAGNOSE(...) will still be replaced with
m4_warn(...) by autoupdate, but autoconf runs will not complain about
AC_DIAGNOSE. The bulk of the patch is augmenting AU_DEFUN so that it
can define a “silent” autoupdate replacement, and documenting the new
feature.
* lib/autoconf/autoupdate.m4 (AU_DEFUN): Add a fourth argument, SILENT,
which must be either empty or the word ‘silent’. If it is ‘silent’,
the macro being defined will *not* issue a -Wobsolete warning when
expanded by autoconf.
Tweak quotation to prevent emacs’ parenthesis matching from getting
confused.
(AU_ALIAS): Add the SILENT argument here as well.
* lib/autoconf/general.m4 (AC_DIAGNOSE): Define as a silent AU_DEFUN.
Add commentary explaining why this was done and when it can be
changed back.
* doc/autoconf.texi (AU_DEFUN, AU_ALIAS): Revise; document new SILENT
argument.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The changes are now classified into “backward incompatibilities”,
“new features”, “obsolete features and new warnings”,
“notable bug fixes”, and “autotest enhancements”.
Also make the warning about argument-quotation bugs more prominent
and explicit. (See for instance Savannah bug 110319.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
I forgot that you can’t start an awk action block on the next line
from its condition.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the Texinfo documentation consistent with the previous
changes. --help output regarding warnings is already drawn directly
from ChannelDefs.pm and thus does not need to be updated.
* doc/autoconf.texi: Update all ‘invocation’ sections to describe
-W/--warnings consistently, and to refer to m4_warn for the list
of categories.
(m4_warn): Document the complete current list of categories.
(Reporting Messages): Delete section.
(AC_DIAGNOSE, AC_WARNING, AC_FATAL): Move to Obsolete Macros.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
autoreconf runs a bunch of subsidiary tools, and is expected to pass
along various command-line settings, such as those controlling
warnings. It has historically done this via the command line.
However, not all of the tools recognize the same set of command-line
warnings options. There’s an existing check for whether aclocal and
automake understand ‘--warnings’ at all, but it currently assumes that
automake will accept the same set of warnings *categories* that
autoconf does. This hasn’t actually been true for many years
and is known to cause problems; see the discussion starting at
<https://lists.gnu.org/archive/html/autoconf/2020-09/msg00000.html>.
Previous patches in this series (and related patches applied to
automake) have restored agreement between the current development
trunks of the two sets of tools on the set of warnings categories, but
we still need to deal with the possibility of the *installed* tools
not being in agreement.
If we use the WARNINGS environment variable to pass down warnings
options, instead of the command line, then all the tools are already
coded to ignore unknown warning categories, and this ceases to be an
issue. And we no longer need the check for ‘--warnings’ support in
automake, either.
Also, autoreconf as well should suppress warnings from its first
invocation of autoconf, which is for tracing purposes only and may
emit spurious warnings because aclocal.m4 is not yet in place.
* bin/autoreconf.in
($aclocal_supports_warnings, $automake_supports_warnings): Delete.
(@warning): Make local to sub parse_args.
(parse_args): Do not add --warnings options to $autoconf,
$autoheader, $aclocal, or $automake. Instead, set $ENV{WARNINGS}
appropriately. No longer necessary to probe for --warnings support
from aclocal and automake.
(autoreconf_current_directory): Set $ENV{WARNINGS} temporarily to
“none” when running autoconf in trace mode. Fix typo in comment.
Close $traces immediately after we’re done with it.
* tests/torture.at (Specific warnings options for autoreconf):
New test.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function merges a list of warnings categories into the environment
variable WARNINGS, returning a new value to set it to. The intended use
is in code of the form
{
local $ENV{WARNINGS} = merge_WARNINGS ("this", "that");
# run a command here with WARNINGS=this,that,etc
}
This is not used yet, but will be in the next patch.
* lib/Autom4te/ChannelDefs.pm (merge_WARNINGS): New function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ChannelDefs.pm *ought* to be kept in sync between automake and autoconf,
because it defines the set of valid -W options, and autoreconf assumes
that it can pass arbitrary -W options to all of the tools it invokes.
However, it isn’t covered by either project’s ‘make fetch’ and it hasn’t
actually *been* in sync for more than 17 years.
This patch manually brings over all of the changes made on the
automake side. Once the complementary patch is applied by the
automake team, both versions of the file will be the same, and then we
can add it to the list in fetch.pl and not have this problem any more
in the future.
There are some user-visible consequences to bringing this file back
into sync. The only one worth mentioning in NEWS is that the ‘obsolete’
category of warnings is now on by default. This had quite a bit of
fallout throughout the testsuite. There are also some new warning
categories that get mentioned in --help output, but we don’t actually
generate any warnings in those categories, so people using ‘-Wall’
won’t see any change. More diagnostics are automatically tagged with
‘warning:’ or ‘error:’, which also had some fallout in the testsuite.
Finally, ‘-Werror’ no longer causes complaints about unknown warning
categories to be treated as hard errors.
Internally, there are some small API changes: ‘parse_warnings’ is no
longer usable as a ‘getopt’ callback function, and we now have a stub
Autom4te/Config.pm to match the automake code’s expectations. (This
file *should* also be synced from automake by ‘make fetch’, but we
can’t quite do that yet because it’s a generated file and our build
system is not prepared to handle adding *two* directories to @INC when
running a not-yet-installed Perl script. I plan to fix that after 2.70.)
As a side-effect of adding a Config.pm, ‘prog_error’ now says to
report the bug to bug-autoconf, not bug-automake. If this is why we
mostly haven’t been using prog_error for internal errors, we can stop
avoiding it. (I did not change anything to use prog_error in this
patch.)
* lib/Autom4te/ChannelDefs.pm: Merge from automake.
* lib/Autom4te/Config.pm: New file.
* lib/local.mk (dist_perllib_DATA): Add Autom4te/Config.pm.
* bin/autoconf.as: Update list of warning categories to match
Autom4te::ChannelDefs::usage.
* bin/autoheader.in (@warnings): New global.
(parse_args): Don’t use parse_warnings as a getopt callback.
(main): Add warnings options from our command line to $autoconf.
No need to turn on 'obsolete' warnings explicitly.
No need to include "warning: " in warning messages.
* bin/autom4te.in (parse_args): Don’t use parse_warnings as a getopt callback.
(main): No need to include "warning: " in warning messages.
* bin/autoreconf.in (parse_args): parse_warnings now takes only one argument.
* bin/autoupdate.in: Set WARNINGS=none in environment for all child processes.
* tests/local.at
(AT_CHECK_M4): Handle `autom4te: error: /usr/bin/m4 ...` like
`autom4te: /usr/bin/m4 ...`.
(_AT_CHECK_AC_MACRO): Add AUTOCONF-FLAGS argument, passed to both
autoconf and autoheader.
(AT_CHECK_MACRO): Default AUTOCONF-FLAGS argument to empty.
Pass that argument to autoheader as well as autoconf.
(AT_CHECK_AU_MACRO): Expect a “macro ‘NAME’ is obsolete’ diagnostic
on the first run of autoconf. Pass -Wno-obsolete to autoconf on the
second run, and to autoheader on both runs.
* tests/base.at
* tests/c.at
* tests/compile.at
* tests/m4sh.at
* tests/m4sugar.at
* tests/semantics.at
* tests/tools.at
* tests/torture.at:
No need to pass -Wobsolete to autoconf.
Pass -Wno-obsolete to autoheader where needed to avoid handling
the same warning twice.
Update various expectations for diagnostics to match behavior
changes.
* tests/tools.at (autoupdating AU_ALIAS): Add an AC_CONFIG_HEADERS
line to the test configure.ac to eliminate an unrelated diagnostic.
|
| |
|
|
|
|
| |
The documentation for AC_TRY_LINK has a cross-reference to "Running
the Compiler". This should be "Running the Linker" instead. Also
make the link in AC_TRY_LINK_FUNC consistent.
|
| |
|
|
|
|
|
|
|
| |
Commit 9b5c0f17741836e99d0a801c6309389d391c03f9 introduced a bug where
autoconf --help would only print “Try 'autoconf --help' for more information.”
Correct this.
* bin/autoconf.as: Print $help, not $usage_err, for --help.
Consistently use AS_ECHO, not bare echo.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
* doc/autoconf.texi (File Descriptors): Mention a problem of Solaris 10.
Mention that a known problem also occurs in dash.
|
| | |
|
