Too many legacy tools exist for us to unilaterally quit supporting
AC_CONFIG_MACRO_DIR - it is feasible for someone to want their
package to bootstrap with both automake 1.13 and libtool 2.4.2,
where the newer automake will only trace the new style of multiple
directory listings, but the older libtool does a sed and settles
on the one use of the old name. So, we let both macros forward
to a new tracing macro, which also has the benefit of sanitizing
calls into one directory per trace; we also ensure that the old
macro is always traced, and appears at most once and before any
use of the new macro.
* doc/autoconf.texi (Input) <AC_CONFIG_MACRO_DIRS>: Document how
to trace this macro.
* lib/autom4te.in (Autoreconf-preselections)
(Automake-preselections): Preselect this trace.
* lib/autoconf/general.m4 (AC_CONFIG_MACRO_DIR_TRACE): New trace.
(_AC_CONFIG_MACRO_DIRS_USED, _AC_CONFIG_MACRO_DIRS): New internal
macros.
(AC_CONFIG_MACRO_DIRS, AC_CONFIG_MACRO_DIR): Use them.
* tests/tools.at (autoconf --trace: AC_CONFIG_MACRO_DIRS): New
test.
We introduce a new witness macro, m4_require_silent_probe, for use by
aclocal during the Autoconf-without-aclocal-m4 language. This will let
aclocal process AC_CONFIG_MACRO_DIRS without emitting spurious warnings.
In fact, if aclocal doesn't suppress require warnings, then, when some macro
expanded in configure.ac calls AC_REQUIRE on another macro that is defined
in one of the local m4 macro dirs specified with AC_CONFIG_MACRO_DIRS, the
*first* autom4te invocation issued by aclocal, not yet being able to "see"
the m4 macro definitions in the local m4 dirs, will print spurious
warnings like:
configure.ac:4: warning: MY_BAR is m4_require'd but not m4_defun'd
configure.ac:3: MY_FOO is expanded from...
Expose the use of this macro in our testsuite.
Originally reported by Nick Bowler; see point (4) of:
<http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00000.html>
* lib/m4sugar/m4sugar.m4 (_m4_require_call): Make warnings in the
-Wsyntax category depend on the witness macro.
* tests/m4sugar.at (m4@&t@_require: warning message): New test.
* doc/autoconf.texi (Prerequisite Macros): Document how aclocal
can silence AC_REQUIRE (m4_require) warnings.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Similar to AC_CONFIG_MACRO_DIR, but accepts more than one argument.
This will allow projects to use several m4 macro local dirs. This is
especially important for projects that are used as nested subpackages
of larger projects.
See also:
<http://lists.gnu.org/archive/html/autoconf/2011-12/msg00037.html>
<http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00010.html>
* lib/autoconf/general.m4 (AC_CONFIG_MACRO_DIRS): New. Expands to the
empty anyway, since it is only meant to be traced by tools like aclocal
and autoreconf.
(AC_CONFIG_MACRO_DIR): Updated comments.
* doc/autoconf.texi (@node "Input"): Document AC_CONFIG_MACRO_DIRS as
preferred over AC_CONFIG_MACRO_DIR.
* NEWS: Update.
Suggested-by: Eric Blake <eblake@redhat.com>
Helped-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
* lib/autom4te.in: Here, the comment about 'AM_PROG_MKDIR_P'.
Suggested-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
This fixes a bug introduced by the most recent change to c.m4.
Problem reported by Jim Meyering in
<http://lists.gnu.org/archive/html/autoconf/2012-10/msg00048.html>.
* lib/autoconf/c.m4 (AC_PROG_CC_C89, AC_PROG_CC_C99, AC_PROG_CC_STDC):
Use AU_DEFUN and AC_REQUIRE, not AU_ALIAS, as the latter is not
compatible with how Automake redefines AC_PROG_CC.
* doc/autoconf.texi (C Compiler): Document the intent of AC_PROG_CC
better. It's not meant to check for strict conformance, only to
get the latest version with extensions.
(Running the Preprocessor, Present But Cannot Be Compiled):
Document new diagnostic wording.
* lib/autoconf/c.m4 (_AC_C_STD_TRY): Change diagnostic wording from
"checking for gcc option to accept ISO C11" to
"checkint for gcc option to enable C11 features", as this better
reflects what is actually happening.
(_AC_PROG_CC_C99): Put -qlanglvl=extc1x here ...
(_AC_PROG_CC_C11): ... rather than here, as it doesn't pass the C11
test with IBM XL C V12.1, and the point is to enable features not to
test for strict conformance.
* lib/autoconf/c.m4 (_AC_PROG_CC_C11): Add -qlanglvl=extc1x, for
IBM XL C V12.1. It shouldn't pass the C11 test yet, since it's not
documented to support _Alignas, _Alignof, UTF-8 string literals,
and duplicate typedefs, but presumably it will eventually.
* NEWS:
* doc/autoconf.texi (C Compiler, Running the Preprocessor)
(Limitations of Usual Tools, Present But Cannot Be Compiled)
(Obsolete Macros):
Document the changes described below.
* lib/autoconf/c.m4 (_AC_PROG_CC_FORCE_VERSION): Remove.
(AC_PROG_CC_C89, AC_PROG_CC_C99, AC_PROG_CC_STDC):
Just do AC_PROG_CC, but mark as obsolete. This replaces my recent
ill-advised attempt to let AC_PROG_CC_C89 and AC_PROG_CC_C99 downgrade
the version of C supported.
* doc/autoconf.texi (Limitations of Usual Tools, Volatile Objects):
Document C11 more accurately. In some cases this involves removing
some details about 'volatile', alas, since C11 changed this stuff.
Again.
Issue revealed by a failure in test "35: tools.at: autom4te preselections":
<http://lists.gnu.org/archive/html/bug-autoconf/2012-09/msg00020.html>
* lib/autom4te.in: Add 'AM_PROG_MKDIR_P'.
Helped-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
* NEWS:
* doc/autoconf.texi (C Compiler): Document the following.
* lib/autoconf/c.m4 (AC_PROG_CC): Check for the latest C version
supported, not just C89.
(_AC_C_STD_TRY): Keep track of the options we add to bring
the C compiler up to standard, so that we can undo it if the
user later requests some other C standard.
(_AC_PROG_CC_FORCE_VERSION): New macro.
(AC_PROG_CC_C89, AC_PROG_CC_C99): Use it. These macros now
have a documented side effect of changing the C version requested.
(AC_PROG_CC_C11): Remove. It wasn't useful.
(AC_PROG_CC_STDC): Now an obsolescent alias for AC_PROG_CC.
(AC_C_PROTOTYPES): Allow any standard C version, not just c89.
Don't chatter, since we don't actually run any checking code.
* lib/autoconf/types.m4 (AC_TYPE_LONG_LONG_INT)
(AC_TYPE_UNSIGNED_LONG_LONG_INT): Treat C11 like C99.
* TODO: Remove the TODO item corresponding to the above.
* doc/autoconf.texi (Default Includes, Particular Functions)
(Header Portability):
* lib/autoconf/c.m4 (AC_LANG_FUNC_LINK_TRY(C)):
* lib/autoconf/headers.m4 (AC_HEADER_STDC):
* lib/autoconf/types.m4 (_AC_CHECK_ALIGNOF):
* lib/m4sugar/m4sugar.m4 (m4_require) [comment only]:
Assume the existence of the C89 freestanding headers <float.h>,
<limits.h>, <stdarg.h>, <stddef.h>, as that's safe nowadays.
This is less likely to run into gotchas, and should fix a
cross-compilation bug with newer GCC reported by Myke Frysinger in
<http://lists.gnu.org/archive/html/bug-autoconf/2012-09/msg00001.html>.
* NEWS:
* doc/autoconf.texi (C Compiler): Document this.
(Gnulib, Function Portability, Particular Functions)
(Header Portability, Particular Headers, Defining Symbols)
(Printing Messages, Limitations of Usual Tools)
(Preprocessor Arithmetic, Volatile Objects, Exiting Portably):
Modernize wording for C11.
* lib/autoconf/c.m4 (_AC_C_C99_TEST_HEADER, _AC_C_C99_TEST_BODY):
New macros, taken from _AC_PROG_CC_C99. These are so that we can
also include the C99 tests in the C11 test program.
(_AC_PROG_CC_C99): Use them.
(_AC_PROG_CC_C11, AC_PROG_CC_C11): New macros.
(AC_PROG_CC_STDC): Prefer C11 to C99 or C89.
Consider the following:
% cat >configure.ac <<'EOF'
AC_INIT([test], [0])
m4_define([FOO], [baz])
AC_SUBST([FOO], [bar])
AC_CONFIG_FILES([test])
AC_OUTPUT
EOF
% cat >test.in <<'EOF'
@FOO@
EOF
This produces no error messages at autoconf time and none at configure
time. Nevertheless, the substituted value of FOO is the empty string,
instead of bar, as expected. Sure enough, in the output variables
section of config.log, we see FOO='' instead of FOO='bar'. Looking
at the generated configure script, we see that AC_SUBST has produced
baz=bar in the output, instead of the expected FOO=bar. But this is
the only place: everywhere else is still using FOO.
* lib/autoconf/general.m4 (AC_SUBST): Add another layer of
quoting.
* THANKS: Update.
Signed-off-by: Eric Blake <eblake@redhat.com>
IFS may be modified temporarily when the configure script receives a
signal. Make sure the EXIT trap uses the standard value.
* lib/autoconf/general.m4: Sanitize IFS in trap.
* THANKS: Update.
Copyright-paperwork-exempt: Yes
As reported by Paul Keir on the cygwin lists,
http://cygwin.com/ml/cygwin/2012-07/msg00263.html,
some people like to stick / in their $PATH, and if we then try
to probe $as_dir/progname for existence, we can end up causing
cygwin to have a several-second timeout per //name probe. It
is better to avoid inserting the extra slash when $as_dir is the
root directory, and simpler to code by always having a trailing
slash present than it is to strip a trailing slash. Thankfully,
_AS_PATH_WALK is an undocumented interface, and even if someone
was using it in spite of the warnings, their use of $as_dir/foo
will typically only lead to odd-looking /dir//foo probes, with
only the case of / in $PATH causing slowdowns, and only when //
is special.
There was also a minor bug where the if-not-found code of
_AS_PATH_WALK could be executed with $IFS still in the wrong state.
* lib/m4sugar/m4sh.m4 (_AS_PATH_WALK): Always end as_dir in /.
Avoid wrong IFS during if-not-found. Minor optimization to avoid
regex.
(_AS_DETECT_BETTER_SHELL, _AS_SHELL_SANITIZE): Update clients.
* lib/autotest/general.m4 (_AT_FINISH): Likewise.
* lib/autoconf/programs.m4 (_AC_CHECK_PROG, _AC_PATH_PROG)
(_AC_PATH_PROGS_FEATURE_CHECK, _AC_PATH_PROG_FLAVOR_GNU): Likewise.
Cater to the Bitrig OS, an OpenBSD fork. config.guess and
config.sub have been updated upstream.
* lib/autoconf/functions.m4 (_AC_FUNC_MALLOC_IF)
(_AC_FUNC_REALLOC_IF): Bitrig inherits from BSD.
It has been years since that has been deprecated in the documentation,
in favour of 'configure.ac':
Previous versions of Autoconf promoted the name configure.in, which
is somewhat ambiguous (the tool needed to process this file is not
described by its extension), and introduces a slight confusion with
config.h.in and so on (for which '.in' means "to be processed by
configure"). Using configure.ac is now preferred.
It's now time to start giving runtime warning about the use of
'configure.in', so that support for it can be removed in future
versions of autoconf/automake.
* lib/Autom4te/Configure_ac.pm: Issue a warning in the 'obsolete'
category if 'configure.in' is detected. Since this module is synced
from Automake, this change is to be backported there (and will be
soon).
* doc/autoconf.texi: Update.
* tests/tools.at: Adjust to avoid spurious failures.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Paul and Eric suggested that improving the cross-compilation guesses
for targets that are glibc systems would be welcome here [1][2].
This patch modifies the cross-compilation behaviour of
AC_FUNC_CHOWN
AC_FUNC_GETGROUPS
AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
AC_FUNC_MALLOC
AC_FUNC_MMAP
AC_FUNC_REALLOC
AC_FUNC_STRCOLL
so that when the target is a glibc system (or, in case of AC_FUNC_MALLOC
and AC_FUNC_REALLOC, any known "good" Unix system), the guess is
"yes it works" rather than "guessing no".
This is important because some of these macros are used in Gnulib, and
in case of "guessing no" Gnulib provides extra workaround code, and
1) Generally, when targetting embedded systems, code size should be
minimized,
2) In [3], unnecessary workaround code will look like a Glibc bug.
This patch also changes the configure output to "guessing yes" or
"guessing no" in a case where the ac_cv_* variable is undocumented.
[1] http://lists.gnu.org/archive/html/bug-gnulib/2012-05/msg00010.html
[2] http://lists.gnu.org/archive/html/bug-gnulib/2012-05/msg00013.html
[3] http://sourceware.org/glibc/wiki/Testing/Gnulib
This patch was tested with the simple configure.ac file
=============== configure.ac ==================
AC_INIT([dummy], [0])
AC_FUNC_CHOWN
AC_FUNC_GETGROUPS
AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
AC_FUNC_MALLOC
AC_FUNC_MMAP
AC_FUNC_REALLOC
AC_FUNC_STRCOLL
AC_OUTPUT
===============================================
* lib/autoconf/functions.m4 (AC_FUNC_CHOWN): Require AC_CANONICAL_HOST.
When cross-compiling to a glibc system, guess yes.
(AC_FUNC_GETGROUPS): Likewise.
(AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK): Likewise.
(AC_FUNC_STRCOLL): Likewise.
(_AC_FUNC_MALLOC_IF): Require AC_CANONICAL_HOST. When cross-compiling
to a know Unix system other than AIX and OSF/1, guess yes.
(_AC_FUNC_REALLOC_IF): Likewise.
(AC_FUNC_MMAP): Require AC_CANONICAL_HOST. When cross-compiling to a
system with a Linux kernel, guess yes.
On bi-arch systems (such as x86 / x86_64) it is often necessary to pass
the --host option together with an appropriate value for CC. But this
triggers a warning:
$ ./configure --host=i686-pc-linux-gnu CC="gcc -m32 -march=i586"
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
..
This warning was introduced on 2000-06-30, in commit
<http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=cb2e761b8e1181f97e8e09d85526bd22078433db>
with the remark "Re-enable the old behavior of --host and --build."
This warning was meant to warn users about a changed semantics of
--build and --host. This change is now 12 years in the past; users
have had enough time to learn it. I therefore suggest to remove the
warning.
I've done lots of cross and bi-arch compilations in the last 10 years,
all with --host and without --build, and have never observed a problem
with it, except for the warning. Simply relying on config.guess is sufficient.
* lib/autoconf/general.m4 (_AC_INIT_PARSE_ARGS): Don't warn if --host
given without --build.
Signed-off-by: Eric Blake <eblake@redhat.com>
* lib/Autom4te/General.pm: This file is *not* used by Automake;
adjust comments accordingly.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
This reduces the implicit requirement from 5.6.2 back to 5.6,
while raising the explicit requirement to match the actual code.
* configure.ac (PERL): Fail up front if perl is too old.
* NEWS: Document this.
* README: Likewise.
* README-hacking: Likewise.
* lib/Autom4te/ChannelDefs.pm: Bump requirement.
* lib/Autom4te/General.pm: Relax requirement.
Since the perl version required in Automake::Getopt has been
recently lowered from 5.6.2 to 5.6.0, this change has the nice
effect of making autoconf compatible again with all perls in
the 5.6.x release series.
* maint.mk: Resync via 'make fetch'.
* lib/Autom4te/Channels.pm: Likewise.
* lib/Autom4te/Configure_ac.pm: Likewise.
* lib/Autom4te/FileUtils.pm: Likewise.
* lib/Autom4te/Getopt.pm: Likewise.
* lib/Autom4te/XFile.pm: Likewise.
The module Automake::Struct has been removed in automake master
branch (with yesterday's commit v1.11-2055-g74a7f49 "maint: drop
'Automake::Struct' module"): since Automake now requires Perl 5.6,
that module has become obsolete, being basically just a backport
of Perl 5.6's 'Class::Struct' to Perl 5.5. With this change, we
follow suite in Autoconf, which syncs some of its internal modules
with Automake.
* lib/Autom4te/Struct.pm: Delete.
* lib/Autom4te/Makefile.am (dist_perllib_DATA): Don't list it
anymore.
* cfg.mk: Don't sync it with the Automake repository anymore.
* lib/Autom4te/Request.pm: Use 'Class::Struct' instead of
'Autom4te::Struct'.
It turns out our guard against infinite recursion wasn't good
enough when shells without $LINENO support were involved, since
the creation-and-sourcing of configure.lineno broke the guard's
expectations. Reports by Tim Rice and Paul Eggert.
* lib/m4sugar/m4sh.m4 (_AS_LINENO_PREPARE): Export '_as_can_reexec'
to "no" before sourcing the just-created configure.lineno.
In the process of making it public, factor it into a reusable
function. This makes constructs like AC_CHECK_PROGRAM smaller,
as well as making libtool's naughty use of $as_executable_p safer.
* lib/m4sugar/m4sh.m4 (_AS_TEST_PREPARE): Add a shell function.
(AS_EXECUTABLE_P): Forward to shell function.
* doc/autoconf.texi (Common Shell Constructs): Document it.
* NEWS: Mention this.
Signed-off-by: Eric Blake <eblake@redhat.com>
4.3BSD is no longer a reasonable portability target; and we are
pretty sure that these days we can find at least one shell on any
platform that supports 'test -x'. Drop a horribly unsafe use of
eval as a result. :)
Libtool still uses $as_executable_p without so much as calling
either AS_TEST_X or AS_EXECUTABLE_P; even though the latter has
existed, although undocumented, since at least 2.59; furthermore,
libtool uses it in a context where filtering out directories
would have been desirable. Shame on them.
* lib/m4sugar/m4sh.m4 (_AS_TEST_X_WORKS): New probe.
(AS_SHELL_SANITIZE, AS_INIT): Use it in shell searching.
(AS_TEST_X, AS_EXECUTABLE_P): Simplify.
Signed-off-by: Eric Blake <eblake@redhat.com>
* lib/Autom4te/Getopt.am: The master copy of this file has
been moved to the Automake repository (see Automake commit
'v1.11-662-g52246cc' 2012-01-18, "cmdline parsing: move into
a dedicated perl module"). So we now we sync it from there,
by listing it ...
* cfg.mk (autom4te_files): ... in this variable.
* lib/Autom4te/General.pm (getopt): Move the guts of its
implementation ...
* lib/Autom4te/Getopt.pm (parse_options): .. into this function
in the new Autom4te::Getopt module. This will make it simpler
for the implementation to be shared with other projects (right
now, Automake).
* lib/Automake/Makefile.am (dist_perllib_DATA): Add the new
module.
Older versions of Getopt::Long acted bogusly and died when they
where configured with the 'bundling' flag and an argument '-' was
seen on the command line they were parsing. That is no longer
the case though, and has not been for quite a long time: the bug
is no longer present in the 5.6.2 version of perl and the 2.25
version of Getopt::Long (and today, the latest versions of perl
and Getopt::Long are respectively 5.14.2 and 2.38). The obsolete
workaround for that Getopt::Long bug can thus be removed from our
'getopt' function.
It is also worth noting that such a workaround was quite buggy
and brittle itself; for example, a command like this:
"autom4te --output -"
would have caused the incorrect diagnostic:
"autom4te: option `--output' requires an argument"
Much worse, a command like this:
"autom4te --language=autoconf --output - configure.ac"
would have caused the standard input of autom4te to be processed
and copied into the 'configure.ac' file, deleting its pre-existing
content! Surely not what a user would have expected.
After this change, a command like this:
autom4te --language=autoconf --output - - <configure.ac >out
works as expected, processing the input from 'configure.ac' and
writing it to the 'out' file.
* lib/Autom4te/General.pm (use): Require perl version 5.6.2.
(getopt): Remove the old workaround.
Before this change, an incorrect command line usage:
"autom4te --output"
triggered broken diagnostic like:
"autom4te: unrecognized option `--output'"
instead of the expected and correct:
"autom4te: option `--output' requires an argument"
* lib/Autom4te/General.pm (getopt): Give correct diagnostic in
case of usage errors due to missing arguments for options for
which they are mandatory. Code basically copied from automake's
'parse_arguments' private subroutine.
* lib/m4sugar/general.m4 (_AS_DETECT_BETTER_SHELL): Define the macro
`_AS_FORCE_REEXEC_WITH_CONFIG_SHELL' to `yes', so that the code in
`_AS_DETECT_BETTER_SHELL' will cause autoconf-generated configure
scripts to always re-execute themselves with $CONFIG_SHELL, if it's
set in the environment.
* doc/autoconf.texi (config.status Invocation): Update.
* doc/install.texi (Defining Variables): Likewise.
* NEWS: Likewise.
* tests/m4sh.at: Add tests for the new semantics in ...
(Configure re-execs self with CONFIG_SHELL): ... this new
test group.
* lib/m4sugar/m4sh.m4 (_AS_DETECT_BETTER_SHELL): If the m4sh client
has defined the macro `_AS_FORCE_REEXEC_WITH_CONFIG_SHELL' to
"yes", emit code to always re-execute the current script with
$CONFIG_SHELL, if that's set.
* tests/m4sh.at: Add tests for the new and old semantics, in ...
(Re-exec with CONFIG_SHELL, Forced re-exec with CONFIG_SHELL): ...
these new test groups.
This works better for symlinks to directories.
Problem reported by Eli Zaretskii via Werner Lemberg in
<http://lists.gnu.org/archive/html/bug-autoconf/2011-12/msg00006.html>.
* NEWS:
* doc/autoconf.texi (Particular Programs): Document this.
* lib/m4sugar/m4sh.m4 (_AS_LN_S_PREPARE): Implement this.
