[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Autoconf changes, and throughout the years some constructs have been obsoleted. Most of the changes involve the macros, but in some cases the tools themselves, or even some concepts, are now considered obsolete.
You may completely skip this chapter if you are new to Autoconf. Its intention is mainly to help maintainers updating their packages by understanding how to move to more modern constructs.
15.1 Obsolete `config.status' Invocation | Different calling convention | |
15.2 `acconfig.h' | Additional entries in `config.h.in' | |
15.3 Using autoupdate to Modernize `configure.ac' | Automatic update of `configure.ac' | |
15.4 Obsolete Macros | Backward compatibility macros | |
15.5 Upgrading From Version 1 | Tips for upgrading your files | |
15.6 Upgrading From Version 2.13 | Some fresher tips |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
`config.status' now supports arguments to specify the files to instantiate; see Recreating a Configuration, for more details. Before, environment variables had to be used.
The tags of the commands to execute. The default is the arguments given
to AC_OUTPUT
and AC_CONFIG_COMMANDS
in
`configure.ac'.
The files in which to perform `@variable@' substitutions.
The default is the arguments given to AC_OUTPUT
and
AC_CONFIG_FILES
in `configure.ac'.
The files in which to substitute C #define
statements. The
default is the arguments given to AC_CONFIG_HEADERS
; if that
macro was not called, `config.status' ignores this variable.
The symbolic links to establish. The default is the arguments given to
AC_CONFIG_LINKS
; if that macro was not called,
`config.status' ignores this variable.
In Recreating a Configuration, using this old interface, the example would be:
config.h: stamp-h stamp-h: config.h.in config.status CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_FILES= \ CONFIG_HEADERS=config.h ./config.status echo > stamp-h Makefile: Makefile.in config.status CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_HEADERS= \ CONFIG_FILES=Makefile ./config.status |
(If `configure.ac' does not call AC_CONFIG_HEADERS
, there is
no need to set CONFIG_HEADERS
in the make
rules. Equally
for CONFIG_COMMANDS
etc.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In order to produce `config.h.in', autoheader
needs to
build or to find templates for each symbol. Modern releases of Autoconf
use AH_VERBATIM
and AH_TEMPLATE
(see section Autoheader Macros), but in older releases a file, `acconfig.h', contained the
list of needed templates. autoheader
copied comments and
#define
and #undef
statements from `acconfig.h' in
the current directory, if present. This file used to be mandatory if
you AC_DEFINE
any additional symbols.
Modern releases of Autoconf also provide AH_TOP
and
AH_BOTTOM
if you need to prepend/append some information to
`config.h.in'. Ancient versions of Autoconf had a similar feature:
if `./acconfig.h' contains the string `@TOP@',
autoheader
copies the lines before the line containing
`@TOP@' into the top of the file that it generates. Similarly,
if `./acconfig.h' contains the string `@BOTTOM@',
autoheader
copies the lines after that line to the end of the
file it generates. Either or both of those strings may be omitted. An
even older alternate way to produce the same effect in ancient versions
of Autoconf is to create the files `file.top' (typically
`config.h.top') and/or `file.bot' in the current
directory. If they exist, autoheader
copies them to the
beginning and end, respectively, of its output.
In former versions of Autoconf, the files used in preparing a software package for distribution were:
configure.ac --. .------> autoconf* -----> configure +---+ [aclocal.m4] --+ `---. [acsite.m4] ---' | +--> [autoheader*] -> [config.h.in] [acconfig.h] ----. | +-----' [config.h.top] --+ [config.h.bot] --' |
Using only the AH_
macros, `configure.ac' should be
self-contained, and should not depend upon `acconfig.h' etc.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
autoupdate
to Modernize `configure.ac' The autoupdate
program updates a `configure.ac' file that
calls Autoconf macros by their old names to use the current macro names.
In version 2 of Autoconf, most of the macros were renamed to use a more
uniform and descriptive naming scheme. See section Macro Names, for a
description of the new scheme. Although the old names still work
(see section Obsolete Macros, for a list of the old macros and the corresponding
new names), you can make your `configure.ac' files more readable
and make it easier to use the current Autoconf documentation if you
update them to use the new macro names.
If given no arguments, autoupdate
updates `configure.ac',
backing up the original version with the suffix `~' (or the value
of the environment variable SIMPLE_BACKUP_SUFFIX
, if that is
set). If you give autoupdate
an argument, it reads that file
instead of `configure.ac' and writes the updated file to the
standard output.
autoupdate
accepts the following options:
Print a summary of the command line options and exit.
Print the version number of Autoconf and exit.
Report processing steps.
Don't remove the temporary files.
Force the update even if the file has not changed. Disregard the cache.
Also look for input files in dir. Multiple invocations accumulate. Directories are browsed from last to first.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Several macros are obsoleted in Autoconf, for various reasons (typically they failed to quote properly, couldn't be extended for more recent issues etc.). They are still supported, but deprecated: their use should be avoided.
During the jump from Autoconf version 1 to version 2, most of the macros were renamed to use a more uniform and descriptive naming scheme, but their signature did not change. See section Macro Names, for a description of the new naming scheme. Below, if there is just the mapping from old names to new names for these macros, the reader is invited to refer to the definition of the new macro for the signature and the description.
AC_FUNC_ALLOCA
removed because of limited usefulness
This macro is obsolete; it does nothing.
Determine the system type and set output variables to the names of the canonical system types. See section Getting the Canonical System Type, for details about the variables this macro sets.
The user is encouraged to use either AC_CANONICAL_BUILD
, or
AC_CANONICAL_HOST
, or AC_CANONICAL_TARGET
, depending on
the needs. Using AC_CANONICAL_TARGET
is enough to run the two
other macros.
AC_C_CHAR_UNSIGNED
Autoconf, up to 2.13, used to provide this version of
AC_CHECK_TYPE
, deprecated because of its flaws. Firstly, although
it is a member of the CHECK
clan, singular sub-family, it does
more than just checking. Secondly, missing types are not
typedef
'd, they are #define
'd, which can lead to
incompatible code in the case of pointer types.
This use of AC_CHECK_TYPE
is obsolete and discouraged; see
Generic Type Checks, for the description of the current macro.
If the type type is not defined, define it to be the C (or C++) builtin type default, e.g., `short' or `unsigned'.
This macro is equivalent to:
AC_CHECK_TYPE([type],, [AC_DEFINE_UNQUOTED([type], [default], [Define to `default' if <sys/types.h> does not define.])]) |
In order to keep backward compatibility, the two versions of
AC_CHECK_TYPE
are implemented, selected by a simple heuristics:
If there are three or four arguments, the modern version is used.
If the second argument appears to be a C or C++ type, then the obsolete version is used. This happens if the argument is a C or C++ builtin type or a C identifier ending in `_t', optionally followed by one of `[(* ' and then by a string of zero or more characters taken from the set `[]()* _a-zA-Z0-9'.
If the second argument is spelled with the alphabet of valid C and C++ types, the user is warned and the modern version is used.
Otherwise, the modern version is used.
You are encouraged either to use a valid builtin type, or to use the
equivalent modern code (see above), or better yet, to use
AC_CHECK_TYPES
together with
#if !HAVE_LOFF_T typedef loff_t off_t; #endif |
Same as `AC_MSG_NOTICE([checking feature-description…]'.
This is an obsolete version of AC_TRY_COMPILE
itself replaced by
AC_COMPILE_IFELSE
(see section Running the Compiler), with the
addition that it prints `checking for echo-text' to the
standard output first, if echo-text is non-empty. Use
AC_MSG_CHECKING
and AC_MSG_RESULT
instead to print
messages (see section Printing Messages).
AC_C_CONST
Same as AC_C_CROSS
, which is obsolete too, and does nothing
:-)
.
Check for the Cygwin environment in which case the shell variable
CYGWIN
is set to `yes'. Don't use this macro, the dignified
means to check the nature of the host is using
AC_CANONICAL_HOST
. As a matter of fact this macro is defined as:
AC_REQUIRE([AC_CANONICAL_HOST])[]dnl case $host_os in *cygwin* ) CYGWIN=yes;; * ) CYGWIN=no;; esac |
Beware that the variable CYGWIN
has a very special meaning when
running CygWin32, and should not be changed. That's yet another reason
not to use this macro.
Same as `AC_CHECK_DECLS([sys_siglist])'.
Does nothing, now integrated in AC_PROG_LEX
.
Like calling AC_FUNC_CLOSEDIR_VOID
andAC_HEADER_DIRENT
,
but defines a different set of C preprocessor macros to indicate which
header file is found:
Header | Old Symbol | New Symbol |
`dirent.h' | | |
`sys/ndir.h' | | |
`sys/dir.h' | | |
`ndir.h' | | |
If on DYNIX/ptx, add `-lseq' to output variable
LIBS
. This macro used to be defined as
AC_CHECK_LIB(seq, getmntent, LIBS="-lseq $LIBS") |
now it is just AC_FUNC_GETMNTENT
.
Defined the output variable EXEEXT
based on the output of the
compiler, which is now done automatically. Typically set to empty
string if Unix and `.exe' if Win32 or OS/2.
Similar to AC_CYGWIN
but checks for the EMX environment on OS/2
and sets EMXOS2
.
AC_MSG_ERROR
AC_PATH_X
AC_PATH_XTRA
AC_CHECK_FUNC
If wait3
is found and fills in the contents of its third argument
(a `struct rusage *'), which HP-UX does not do, define
HAVE_WAIT3
.
These days portable programs should use waitpid
, not
wait3
, as wait3
is being removed from the Open Group
standards, and will not appear in the next revision of POSIX.
AC_PROG_GCC_TRADITIONAL
AC_TYPE_GETGROUPS
AC_FUNC_GETLOADAVG
AC_CHECK_FUNCS
AC_CHECK_HEADERS
This macro is equivalent to calling AC_CHECK_LIB
with a
function argument of main
. In addition, library can
be written as any of `foo', `-lfoo', or `libfoo.a'. In
all of those cases, the compiler is passed `-lfoo'. However,
library cannot be a shell variable; it must be a literal name.
AC_SYS_INTERPRETER
(different calling convention)
AC_CHECK_HEADER
AC_EGREP_HEADER
Formerly AC_INIT
used to have a single argument, and was
equivalent to:
AC_INIT AC_CONFIG_SRCDIR(unique-file-in-source-dir) |
AC_C_INLINE
If the C type int
is 16 bits wide, define INT_16_BITS
.
Use `AC_CHECK_SIZEOF(int)' instead.
If on IRIX (Silicon Graphics UNIX), add `-lsun' to output
LIBS
. If you were using it to get getmntent
, use
AC_FUNC_GETMNTENT
instead. If you used it for the NIS versions
of the password and group functions, use `AC_CHECK_LIB(sun,
getpwnam)'. Up to Autoconf 2.13, it used to be
AC_CHECK_LIB(sun, getmntent, LIBS="-lsun $LIBS") |
now it is defined as
AC_FUNC_GETMNTENT AC_CHECK_LIB(sun, getpwnam) |
Same as `AC_LANG(C)'.
Same as `AC_LANG(C++)'.
Same as `AC_LANG(Fortran 77)'.
Select the language that is saved on the top of the stack, as set
by AC_LANG_SAVE
, remove it from the stack, and call
AC_LANG(language)
.
Remember the current language (as set by AC_LANG
) on a stack.
The current language does not change. AC_LANG_PUSH
is preferred.
This is an obsolete version of AC_CONFIG_LINKS
. An updated
version of:
AC_LINK_FILES(config/$machine.h config/$obj_format.h, host.h object.h) |
is:
AC_CONFIG_LINKS(host.h:config/$machine.h object.h:config/$obj_format.h) |
AC_PROG_LN_S
Define LONG_64_BITS
if the C type long int
is 64 bits wide.
Use the generic macro `AC_CHECK_SIZEOF([long int])' instead.
AC_C_LONG_DOUBLE
AC_SYS_LONG_FILE_NAMES
AC_HEADER_MAJOR
Used to define NEED_MEMORY_H
if the mem
functions were
defined in `memory.h'. Today it is equivalent to
`AC_CHECK_HEADERS(memory.h)'. Adjust your code to depend upon
HAVE_MEMORY_H
, not NEED_MEMORY_H
; see Standard Symbols.
Similar to AC_CYGWIN
but checks for the MingW32 compiler
environment and sets MINGW32
.
AC_PROG_CC_C_O
AC_FUNC_MMAP
AC_TYPE_MODE_T
Defined the output variable OBJEXT
based on the output of the
compiler, after .c files have been excluded. Typically set to `o'
if Unix, `obj' if Win32. Now the compiler checking macros handle
this automatically.
Make M4 print a message to the standard error output warning that
this-macro-name is obsolete, and giving the file and line number
where it was called. this-macro-name should be the name of the
macro that is calling AC_OBSOLETE
. If suggestion is given,
it is printed at the end of the warning message; for example, it can be
a suggestion for what to use instead of this-macro-name.
For instance
AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl |
You are encouraged to use AU_DEFUN
instead, since it gives better
services to the user.
AC_TYPE_OFF_T
The use of AC_OUTPUT
with argument is deprecated. This obsoleted
interface is equivalent to:
AC_CONFIG_FILES(file…) AC_CONFIG_COMMANDS([default], extra-cmds, init-cmds) AC_OUTPUT |
Specify additional shell commands to run at the end of
`config.status', and shell commands to initialize any variables
from configure
. This macro may be called multiple times. It is
obsolete, replaced by AC_CONFIG_COMMANDS
.
Here is an unrealistic example:
fubar=27 AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.], [fubar=$fubar]) AC_OUTPUT_COMMANDS([echo this is another, extra, bit], [echo init bit]) |
Aside from the fact that AC_CONFIG_COMMANDS
requires an
additional key, an important difference is that
AC_OUTPUT_COMMANDS
is quoting its arguments twice, unlike
AC_CONFIG_COMMANDS
. This means that AC_CONFIG_COMMANDS
can safely be given macro calls as arguments:
AC_CONFIG_COMMANDS(foo, [my_FOO()]) |
Conversely, where one level of quoting was enough for literal strings
with AC_OUTPUT_COMMANDS
, you need two with
AC_CONFIG_COMMANDS
. The following lines are equivalent:
AC_OUTPUT_COMMANDS([echo "Square brackets: []"]) AC_CONFIG_COMMANDS([default], [[echo "Square brackets: []"]]) |
AC_TYPE_PID_T
AC_PREFIX_PROGRAM
This macro has been integrated into AC_PROG_CC
.
AC_CHECK_PROGS
AC_PATH_PROGS
AC_CHECK_PROG
AC_EGREP_CPP
AC_PATH_PROG
removed because of limited usefulness
AC_SYS_RESTARTABLE_SYSCALLS
AC_TYPE_SIGNAL
removed because of limited usefulness
If on SCO UNIX, add `-lintl' to output variable LIBS
. This
macro used to
AC_CHECK_LIB(intl, strftime, LIBS="-lintl $LIBS") |
Now it just calls AC_FUNC_STRFTIME
instead.
AC_FUNC_SETVBUF_REVERSED
AC_PROG_MAKE_SET
AC_CHECK_SIZEOF
AC_TYPE_SIZE_T
AC_HEADER_STAT
AC_HEADER_STDC
AC_FUNC_STRCOLL
AC_CHECK_MEMBERS
AC_STRUCT_ST_BLOCKS
AC_CHECK_MEMBERS
If the system automatically restarts a system call that is interrupted
by a signal, define HAVE_RESTARTABLE_SYSCALLS
. This macro does
not check if system calls are restarted in general-it tests whether a
signal handler installed with signal
(but not sigaction
)
causes system calls to be restarted. It does not test if system calls
can be restarted when interrupted by signals that have no handler.
These days portable programs should use sigaction
with
SA_RESTART
if they want restartable system calls. They should
not rely on HAVE_RESTARTABLE_SYSCALLS
, since nowadays whether a
system call is restartable is a dynamic issue, not a configuration-time
issue.
AC_DECL_SYS_SIGLIST
AC_TRY_CPP
, replaced with AC_PREPROC_IFELSE
.
AC_TRY_RUN
, replaced with AC_RUN_IFELSE
.
AC_STRUCT_TIMEZONE
AC_HEADER_TIME
Same as `AC_COMPILE_IFELSE([AC_LANG_SOURCE([[includes]], [[function-body]])], [action-if-true], [action-if-false])' (see section Running the Compiler).
This macro double quotes both includes and function-body.
For C and C++, includes is any #include
statements needed
by the code in function-body (includes will be ignored if
the currently selected language is Fortran 77). This macro also uses
CFLAGS
or CXXFLAGS
if either C or C++ is the currently
selected language, as well as CPPFLAGS
, when compiling. If
Fortran 77 is the currently selected language then FFLAGS
will be
used when compiling.
Same as `AC_PREPROC_IFELSE([AC_LANG_SOURCE([[input]])], [action-if-true], [action-if-false])' (see section Running the Preprocessor).
This macro double quotes the input.
Same as `AC_LINK_IFELSE([AC_LANG_SOURCE([[includes]], [[function-body]])], [action-if-true], [action-if-false])' (see section Running the Compiler).
This macro double quotes both includes and function-body.
Depending on the current language (see section Language Choice), create a test program to see whether a function whose body consists of function-body can be compiled and linked. If the file compiles and links successfully, run shell commands action-if-found, otherwise run action-if-not-found.
This macro double quotes both includes and function-body.
For C and C++, includes is any #include
statements needed
by the code in function-body (includes will be ignored if
the currently selected language is Fortran 77). This macro also uses
CFLAGS
or CXXFLAGS
if either C or C++ is the currently
selected language, as well as CPPFLAGS
, when compiling. If
Fortran 77 is the currently selected language then FFLAGS
will be
used when compiling. However, both LDFLAGS
and LIBS
will
be used during linking in all cases.
This macro is equivalent to `AC_LINK_IFELSE([AC_LANG_CALL([[includes]], [[function-body]])], [action-if-true], [action-if-false])'.
Same as `AC_RUN_IFELSE([AC_LANG_SOURCE([[program]], [action-if-true], [action-if-false], [action-if-cross-compiling])' (see section Checking Run Time Behavior).
AC_TYPE_UID_T
Same as `AC_CHECK_HEADERS(unistd.h)'.
Define USG
if the BSD string functions are defined in
`strings.h'. You should no longer depend upon USG
, but on
HAVE_STRING_H
; see Standard Symbols.
AC_FUNC_UTIME_NULL
If the cache file is inconsistent with the current host, target and build system types, it used to execute cmd or print a default error message. This is now handled by default.
AC_MSG_RESULT
.
AC_FUNC_VFORK
AC_FUNC_VPRINTF
AC_FUNC_WAIT3
AC_MSG_WARN
AC_C_BIGENDIAN
This macro used to add `-lx' to output variable LIBS
if on
Xenix. Also, if `dirent.h' is being checked for, added
`-ldir' to LIBS
. Now it is merely an alias of
AC_HEADER_DIRENT
instead, plus some code to detect whether
running XENIX on which you should not depend:
AC_MSG_CHECKING([for Xenix]) AC_EGREP_CPP(yes, [#if defined M_XENIX && !defined M_UNIX yes #endif], [AC_MSG_RESULT([yes]); XENIX=yes], [AC_MSG_RESULT([no]); XENIX=]) |
AC_DECL_YYTEXT
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Autoconf version 2 is mostly backward compatible with version 1.
However, it introduces better ways to do some things, and doesn't
support some of the ugly things in version 1. So, depending on how
sophisticated your `configure.ac' files are, you might have to do
some manual work in order to upgrade to version 2. This chapter points
out some problems to watch for when upgrading. Also, perhaps your
configure
scripts could benefit from some of the new features in
version 2; the changes are summarized in the file `NEWS' in the
Autoconf distribution.
15.5.1 Changed File Names | Files you might rename | |
15.5.2 Changed Makefiles | New things to put in `Makefile.in' | |
15.5.3 Changed Macros | Macro calls you might replace | |
15.5.4 Changed Results | Changes in how to check test results | |
15.5.5 Changed Macro Writing | Better ways to write your own macros |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you have an `aclocal.m4' installed with Autoconf (as opposed to
in a particular package's source directory), you must rename it to
`acsite.m4'. See section Using autoconf
to Create configure
.
If you distribute `install.sh' with your package, rename it to
`install-sh' so make
builtin rules won't inadvertently
create a file called `install' from it. AC_PROG_INSTALL
looks for the script under both names, but it is best to use the new name.
If you were using `config.h.top', `config.h.bot', or
`acconfig.h', you still can, but you will have less clutter if you
use the AH_
macros. See section Autoheader Macros.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Add `@CFLAGS@', `@CPPFLAGS@', and `@LDFLAGS@' in
your `Makefile.in' files, so they can take advantage of the values
of those variables in the environment when configure
is run.
Doing this isn't necessary, but it's a convenience for users.
Also add `@configure_input@' in a comment to each input file for
AC_OUTPUT
, so that the output files will contain a comment saying
they were produced by configure
. Automatically selecting the
right comment syntax for all the kinds of files that people call
AC_OUTPUT
on became too much work.
Add `config.log' and `config.cache' to the list of files you
remove in distclean
targets.
If you have the following in `Makefile.in':
prefix = /usr/local exec_prefix = $(prefix) |
you must change it to:
prefix = @prefix@ exec_prefix = @exec_prefix@ |
The old behavior of replacing those variables without `@' characters around them has been removed.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Many of the macros were renamed in Autoconf version 2. You can still
use the old names, but the new ones are clearer, and it's easier to find
the documentation for them. See section Obsolete Macros, for a table showing the
new names for the old macros. Use the autoupdate
program to
convert your `configure.ac' to using the new macro names.
See section Using autoupdate
to Modernize `configure.ac'.
Some macros have been superseded by similar ones that do the job better,
but are not call-compatible. If you get warnings about calling obsolete
macros while running autoconf
, you may safely ignore them, but
your configure
script will generally work better if you follow
the advice that is printed about what to replace the obsolete macros with. In
particular, the mechanism for reporting the results of tests has
changed. If you were using echo
or AC_VERBOSE
(perhaps
via AC_COMPILE_CHECK
), your configure
script's output will
look better if you switch to AC_MSG_CHECKING
and
AC_MSG_RESULT
. See section Printing Messages. Those macros work best
in conjunction with cache variables. See section Caching Results.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you were checking the results of previous tests by examining the
shell variable DEFS
, you need to switch to checking the values of
the cache variables for those tests. DEFS
no longer exists while
configure
is running; it is only created when generating output
files. This difference from version 1 is because properly quoting the
contents of that variable turned out to be too cumbersome and
inefficient to do every time AC_DEFINE
is called. See section Cache Variable Names.
For example, here is a `configure.ac' fragment written for Autoconf version 1:
AC_HAVE_FUNCS(syslog) case "$DEFS" in *-DHAVE_SYSLOG*) ;; *) # syslog is not in the default libraries. See if it's in some other. saved_LIBS="$LIBS" for lib in bsd socket inet; do AC_CHECKING(for syslog in -l$lib) LIBS="$saved_LIBS -l$lib" AC_HAVE_FUNCS(syslog) case "$DEFS" in *-DHAVE_SYSLOG*) break ;; *) ;; esac LIBS="$saved_LIBS" done ;; esac |
Here is a way to write it for version 2:
AC_CHECK_FUNCS(syslog) if test $ac_cv_func_syslog = no; then # syslog is not in the default libraries. See if it's in some other. for lib in bsd socket inet; do AC_CHECK_LIB($lib, syslog, [AC_DEFINE(HAVE_SYSLOG) LIBS="$LIBS -l$lib"; break]) done fi |
If you were working around bugs in AC_DEFINE_UNQUOTED
by adding
backslashes before quotes, you need to remove them. It now works
predictably, and does not treat quotes (except back quotes) specially.
See section Setting Output Variables.
All of the Boolean shell variables set by Autoconf macros now use `yes' for the true value. Most of them use `no' for false, though for backward compatibility some use the empty string instead. If you were relying on a shell variable being set to something like 1 or `t' for true, you need to change your tests.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When defining your own macros, you should now use AC_DEFUN
instead of define
. AC_DEFUN
automatically calls
AC_PROVIDE
and ensures that macros called via AC_REQUIRE
do not interrupt other macros, to prevent nested `checking…'
messages on the screen. There's no actual harm in continuing to use the
older way, but it's less convenient and attractive. See section Macro Definitions.
You probably looked at the macros that came with Autoconf as a guide for how to do things. It would be a good idea to take a look at the new versions of them, as the style is somewhat improved and they take advantage of some new features.
If you were doing tricky things with undocumented Autoconf internals (macros, variables, diversions), check whether you need to change anything to account for changes that have been made. Perhaps you can even use an officially supported technique in version 2 instead of kludging. Or perhaps not.
To speed up your locally written feature tests, add caching to them. See whether any of your tests are of general enough usefulness to encapsulate them into macros that you can share.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The introduction of the previous section (see section Upgrading From Version 1) perfectly suits this section....
Autoconf version 2.50 is mostly backward compatible with version 2.13. However, it introduces better ways to do some things, and doesn't support some of the ugly things in version 2.13. So, depending on how sophisticated your `configure.ac' files are, you might have to do some manual work in order to upgrade to version 2.50. This chapter points out some problems to watch for when upgrading. Also, perhaps your
configure
scripts could benefit from some of the new features in version 2.50; the changes are summarized in the file `NEWS' in the Autoconf distribution.
15.6.1 Changed Quotation | Broken code which used to work | |
15.6.2 New Macros | Interaction with foreign macros | |
15.6.3 Hosts and Cross-Compilation | Bugward compatibility kludges | |
15.6.4 AC_LIBOBJ vs. LIBOBJS | LIBOBJS is a forbidden token | |
15.6.5 AC_FOO_IFELSE vs. AC_TRY_FOO | A more generic scheme for testing sources |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The most important changes are invisible to you: the implementation of most macros have completely changed. This allowed more factorization of the code, better error messages, a higher uniformity of the user's interface etc. Unfortunately, as a side effect, some construct which used to (miraculously) work might break starting with Autoconf 2.50. The most common culprit is bad quotation.
For instance, in the following example, the message is not properly quoted:
AC_INIT AC_CHECK_HEADERS(foo.h,, AC_MSG_ERROR(cannot find foo.h, bailing out)) AC_OUTPUT |
Autoconf 2.13 simply ignores it:
$ autoconf-2.13; ./configure --silent creating cache ./config.cache configure: error: cannot find foo.h $ |
while Autoconf 2.50 will produce a broken `configure':
$ autoconf-2.50; ./configure --silent configure: error: cannot find foo.h ./configure: exit: bad non-numeric arg `bailing' ./configure: exit: bad non-numeric arg `bailing' $ |
The message needs to be quoted, and the AC_MSG_ERROR
invocation
too!
AC_INIT AC_CHECK_HEADERS(foo.h,, [AC_MSG_ERROR([cannot find foo.h, bailing out])]) AC_OUTPUT |
Many many (and many more) Autoconf macros were lacking proper quotation,
including no less than… AC_DEFUN
itself!
$ cat configure.in AC_DEFUN([AC_PROG_INSTALL], [# My own much better version ]) AC_INIT AC_PROG_INSTALL AC_OUTPUT $ autoconf-2.13 autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_FD_MSG ***BUG in Autoconf--please report*** AC_EPI configure.in:1:AC_DEFUN([AC_PROG_INSTALL], configure.in:5:AC_PROG_INSTALL $ autoconf-2.50 $ |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Because Autoconf has been dormant for years, Automake provided
Autoconf-like macros for a while. Autoconf 2.50 now provides better
versions of these macros, integrated in the AC_
namespace,
instead of AM_
. But in order to ease the upgrading via
autoupdate
, bindings to such AM_
macros are provided.
Unfortunately Automake did not quote the names of these macros!
Therefore, when m4
finds something like
`AC_DEFUN(AM_TYPE_PTRDIFF_T, …)' in `aclocal.m4',
AM_TYPE_PTRDIFF_T
is
expanded, replaced with its Autoconf definition.
Fortunately Autoconf catches pre-AC_INIT
expansions, and will
complain, in its own words:
$ cat configure.in AC_INIT AM_TYPE_PTRDIFF_T $ aclocal-1.4 $ autoconf ./aclocal.m4:17: error: m4_defn: undefined macro: _m4_divert_diversion actypes.m4:289: AM_TYPE_PTRDIFF_T is expanded from... ./aclocal.m4:17: the top level $ |
Future versions of Automake will simply no longer define most of these macros, and will properly quote the names of the remaining macros. But you don't have to wait for it to happen to do the right thing right now: do not depend upon macros from Automake as it is simply not its job to provide macros (but the one it requires itself):
$ cat configure.in AC_INIT AM_TYPE_PTRDIFF_T $ rm aclocal.m4 $ autoupdate autoupdate: `configure.in' is updated $ cat configure.in AC_INIT AC_CHECK_TYPES([ptrdiff_t]) $ aclocal-1.4 $ autoconf $ |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Based on the experience of compiler writers, and after long public debates, many aspects of the cross-compilation chain have changed:
the relationship between the build, host, and target architecture types,
the command line interface for specifying them to configure
,
the variables defined in configure
,
the enabling of cross-compilation mode.
The relationship between build, host, and target have been cleaned up:
the chain of default is now simply: target defaults to host, host to
build, and build to the result of config.guess
. Nevertheless,
in order to ease the transition from 2.13 to 2.50, the following
transition scheme is implemented. Do not rely on it, as it will
be completely disabled in a couple of releases (we cannot keep it, as it
proves to cause more problems than it cures).
They all default to the result of running config.guess
, unless
you specify either `--build' or `--host'. In this case,
the default becomes the system type you specified. If you specify both,
and they're different, configure
will enter cross compilation
mode, so it won't run any tests that require execution.
Hint: if you mean to override the result of config.guess
,
prefer `--build' over `--host'. In the future,
`--host' will not override the name of the build system type.
Whenever you specify --host
, be sure to specify --build
too.
For backward compatibility, configure
will accept a system
type as an option by itself. Such an option will override the
defaults for build, host, and target system types. The following
configure statement will configure a cross toolchain that will run on
NetBSD/alpha but generate code for GNU Hurd/sparc, which is
also the build platform.
./configure --host=alpha-netbsd sparc-gnu |
In Autoconf 2.13 and before, the variables build
, host
,
and target
had a different semantics before and after the
invocation of AC_CANONICAL_BUILD
etc. Now, the argument of
`--build' is strictly copied into build_alias
, and is left
empty otherwise. After the AC_CANONICAL_BUILD
, build
is
set to the canonicalized build type. To ease the transition, before,
its contents is the same as that of build_alias
. Do not
rely on this broken feature.
For consistency with the backward compatibility scheme exposed above, when `--host' is specified but `--build' isn't, the build system will be assumed to be the same as `--host', and `build_alias' will be set to that value. Eventually, this historically incorrect behavior will go away.
The former scheme to enable cross-compilation proved to cause more harm
than good, in particular, it used to be triggered too easily, leaving
regular end users puzzled in front of cryptic error messages.
configure
could even enter cross-compilation mode only
because the compiler was not functional. This is mainly because
configure
used to try to detect cross-compilation, instead of
waiting for an explicit flag from the user.
Now, configure
enters cross-compilation mode if and only if
`--host' is passed.
That's the short documentation. To ease the transition between 2.13 and its successors, a more complicated scheme is implemented. Do not rely on the following, as it will be removed in the near future.
If you specify `--host', but not `--build', when
configure
performs the first compiler test it will try to run
an executable produced by the compiler. If the execution fails, it will
enter cross-compilation mode. This is fragile. Moreover, by the time
the compiler test is performed, it may be too late to modify the
build-system type: other tests may have already been performed.
Therefore, whenever you specify --host
, be sure to specify
--build
too.
./configure --build=i686-pc-linux-gnu --host=m68k-coff |
will enter cross-compilation mode. The former interface, which
consisted in setting the compiler to a cross-compiler without informing
configure
is obsolete. For instance, configure
will
fail if it can't run the code generated by the specified compiler if you
configure as follows:
./configure CC=m68k-coff-gcc |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
AC_LIBOBJ
vs. LIBOBJS
Up to Autoconf 2.13, the replacement of functions was triggered via the
variable LIBOBJS
. Since Autoconf 2.50, the macro
AC_LIBOBJ
should be used instead (see section Generic Function Checks).
Starting at Autoconf 2.53, the use of LIBOBJS
is an error.
This change is mandated by the unification of the GNU Build System
components. In particular, the various fragile techniques used to parse
a `configure.ac' are all replaced with the use of traces. As a
consequence, any action must be traceable, which obsoletes critical
variable assignments. Fortunately, LIBOBJS
was the only problem,
and it can even be handled gracefully (read, "without your having to
change something").
There were two typical uses of LIBOBJS
: asking for a replacement
function, and adjusting LIBOBJS
for Automake and/or Libtool.
As for function replacement, the fix is immediate: use
AC_LIBOBJ
. For instance:
LIBOBJS="$LIBOBJS fnmatch.o" LIBOBJS="$LIBOBJS malloc.$ac_objext" |
should be replaced with:
AC_LIBOBJ([fnmatch]) AC_LIBOBJ([malloc]) |
When asked for automatic de-ANSI-fication, Automake needs
LIBOBJS
'ed filenames to have `$U' appended to the base
names. Libtool requires the definition of LTLIBOBJS
, whose
suffixes are mapped to `.lo'. People used to run snippets such as:
# This is necessary so that .o files in LIBOBJS are also built via # the ANSI2KNR-filtering rules. LIBOBJS=`echo "$LIBOBJS" | sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'` LTLIBOBJS=`echo "$LIBOBJS" | sed 's/\.o/\.lo/g'` AC_SUBST(LTLIBOBJS) |
Note that this code is wrong, because `.o' is not the only possible extension(4)! It should have read:
# This is necessary so that .o files in LIBOBJS are also built via # the ANSI2KNR-filtering rules. LIB@&t@OBJS=`echo "$LIB@&t@OBJS" | sed 's,\.[[^.]]* ,$U&,g;s,\.[[^.]]*$,$U&,'` LTLIBOBJS=`echo "$LIB@&t@OBJS" | sed 's,\.[[^.]]* ,.lo ,g;s,\.[[^.]]*$,.lo,'` AC_SUBST(LTLIBOBJS) |
You no longer have to use this: AC_OUTPUT
normalizes
LIBOBJS
and LTLIBOBJS
(hence it works with any version of
Automake and Libtool). Just remove these lines (autoupdate
cannot handle this task, since this is not a macro).
Note that U
must not be used in your Makefiles.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
AC_FOO_IFELSE
vs. AC_TRY_FOO
Since Autoconf 2.50, internal codes uses AC_PREPROC_IFELSE
,
AC_COMPILE_IFELSE
, AC_LINK_IFELSE
, and
AC_RUN_IFELSE
on the other one hand and AC_LANG_SOURCES
,
and AC_LANG_PROGRAM
on the other hand instead of the deprecated
AC_TRY_CPP
, AC_TRY_COMPILE
, AC_TRY_LINK
, and
AC_TRY_RUN
. The motivations where:
a more consistent interface: AC_TRY_COMPILE
etc. were double
quoting their arguments;
the combinatoric explosion is solved by decomposing on the one hand the generation of sources, and on the other hand executing the program;
this scheme helps supporting more languages than plain C and C++.
In addition to the change of syntax, the philosphy has changed too: while emphasis was put on speed at the expense of accuracy, today's Autoconf promotes accuracy of the testing framework at, ahem..., the expense of speed.
As a perfect example of what is not to be done, here is how to
find out whether a header file contains a particular declaration, such
as a typedef, a structure, a structure member, or a function. Use
AC_EGREP_HEADER
instead of running grep
directly on the
header file; on some systems the symbol might be defined in another
header file that the file you are checking `#include's.
As a (bad) example, here is how you should not check for C preprocessor
symbols, either defined by header files or predefined by the C
preprocessor: using AC_EGREP_CPP
:
AC_EGREP_CPP(yes, [#ifdef _AIX yes #endif ], is_aix=yes, is_aix=no) |
The above example, properly written would (i) use
AC_LANG_PROGRAM
, and (ii) run the compiler:
AC_COMPILE_IFELSE([AC_LANG_PROGRAM( [[#if !defined _AIX # error _AIX not defined #endif ]])], [is_aix=yes], [is_aix=no]) |
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by John Paul Wallington on October, 29 2003 using texi2html 1.67.