Release 2.64 of autoconf is an important release for developers working on old build systems based on it, because it is the release where the "present but cannot be compiled" warning switches behaviour.
Noteworthy changes in autoconf version 2.64
After eight years, AC_CHECK_HEADER
takes
as authoritative the result from the compiler, rather than the
preprocessor, when the “header present but cannot be
compiled” warning is issued. Refer to Section 4.2.2, “Headers Present But Cannot Be Compiled” for the
details on how to fix the related issues.
The internal macro AH_CHECK_HEADERS
has
been removed; while this is an internal change that should not
mean anything to properly-written autotools, this actually
breaks packages using the KDE 3.x autotools-based build
system, in particular the
KDE_CHECK_HEADERS
macro. To work with
autoconf 2.64, KDE3-based software
should replace the calls to the KDE-specific macro with
equivalent calls to the proper, standard
AC_CHECK_HEADERS
macro, after properly
setting up the language to C++ if needed.
There aren't many specific changes in autoconf 2.68; but this version provides a new milestone in the package's history as it solves the (many) regressions that were introduced in the past two versions. For this reason, for the scope of this document, I'll be documenting the changes in 2.66, 2.67 and 2.68 as a single section.
You are encouraged to avoid as much as possible version 2.66 and 2.67 of autoconf. While they do include a few regression fixes against 2.65, they also introduce a much longer series of mistakes and regressions that were fixed only in 2.68.
Noteworthy changes in autoconf version 2.66 through 2.68
Macros designed to check for functionality (more than
presence) of common library functions are being deprecated in
favour of using the gnulib project framework. Eventually,
alternative, slimmer macros might be looked up at the Autoconf
archive. These macros are involved:
AC_FUNC_ERROR_AT_LINE
;
AC_FUNC_LSTAT_FOLLOWS_SLASHED
;
AC_FUNC_MKTIME
,
AC_FUNC_STRTOD
.
The If-Else family of macros (see Section 5, “Custom Autoconf Tests”) has gained a new safety switch to ensure that the source code being compiled is setting the expected defines that were discovered up to that point. If you call any of those macros with a literal text with the source code to work on, you'll be presented with a warning similar to the following:
configure.ac:XX: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
configure.ac:XX: the top level
This means that calling macros such as AC_PREPROC_IFELSE
or
AC_LINK_IFELSE
now requires the use of
AC_LANG_SOURCE
or AC_LANG_PROGRAM
to generate the
source code to compile. As an alternative, the AC_LANG_DEFINES_PROVIDED
macro can be used within the first parameter to stop autoconf
from warning you about it.
It is important to note that you need to ensure that the call to
AC_LANG_SOURCE
is quoted and not expanded, otherwise that will cause
the warning to appear nonetheless. See the following code:
dnl Old-style code (will issue a warning) AC_LINK_IFELSE([int main() { return 0; }], [some=thing], [some=other]) dnl Wrongly updated code (will still issue a warning) AC_LINK_IFELSE(AC_LANG_SOURCE([int main() { return 0; }]), [some=thing], [some=other]) dnl Correctly updated code AC_LINK_IFELSE([AC_LANG_SOURCE([int main() { return 0; }])], [some=thing], [some=other])