-New in 1.13.1:
+New in 1.13.2:
* WARNING: Future backward-incompatibilities!
- - Automake 1.14 will likely require Autoconf 2.70 or later (which is
- still unreleased at the moment of writing, but is planned to be
- released before Automake 1.14 is).
+ - Automake 1.14 will require Autoconf 2.70 or later (which is still
+ unreleased at the moment of writing, but is planned to be released
+ before Automake 1.14 is).
- - Automake 1.14 will likely drop support for the long-deprecated
- 'configure.in' name for the Autoconf input file. You are advised
- to use the recommended name 'configure.ac' instead.
+ - Automake 1.14 will drop support for the long-deprecated 'configure.in'
+ name for the Autoconf input file. You are advised to start using
+ recommended name 'configure.ac' instead, ASAP.
- The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
be removed in Automake 1.14. The $(mkdir_p) make variable and the
- The ACLOCAL_AMFLAGS special make variable will be fully deprecated
in Automake 1.14 (where it will raise warnings in the "obsolete"
category). You are advised to start relying on the new Automake
- support for AC_CONFIG_MACRO_DIRS instead (which is introduced with
- this release; see below for more information).
+ support for AC_CONFIG_MACRO_DIRS instead (which was introduced in
+ Automake 1.13).
- Support for IRIX and the SGI C/C++ compilers will be removed in
Automake 1.14: they have seen their last release in 2006, and SGI
should take precedence over the same-named automake-provided macro
(defined in '/usr/local/share/aclocal-1.14/vala.m4').
+* C compilation, and the AC_PROG_CC and AM_PROG_CC_C_O macros:
+
+ - The 'compile' script is now unconditionally required for all
+ packages that perform C compilation (note that if you are using
+ the '--add-missing' option, automake will fetch that script for
+ you, so you shouldn't need any explicit adjustment).
+ This new behaviour is needed to avoid obscure errors when the
+ 'subdir-objects' option is used, and the compiler is an inferior
+ one that doesn't grasp the combined use of both the "-c -o"
+ options; see discussion about automake bug#13378 for more details:
+ <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
+ <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>
+
+ - Automake will automatically enhance the AC_PROG_CC autoconf macro
+ to make it check, at configure time, that the C compiler supports
+ the combined use of both the "-c -o" options. This "rewrite" of
+ AC_PROG_CC is only meant to be temporary, since future Autoconf
+ versions should provide all the features Automake needs.
+
+ - The AM_PROG_CC_C_O is no longer useful, and its use is a no-op
+ now. Future Automake versions might start warning that this
+ macro is obsolete. For better backward-compatibility, this macro
+ still sets a proper 'ac_cv_prog_cc_*_c_o' cache variable, and
+ define the 'NO_MINUS_C_MINUS_O' C preprocessor symbol, but you
+ should really stop relying on that.
+
+* Obsolescent features:
+
+ - Use of suffix-less info files (that can be specified through the
+ '@setfilename' macro in Texinfo input files) is discouraged, and
+ its use will raise warnings in the 'obsolete' category. Simply
+ use the '.info' extension for all your info files, transforming
+ usages like:
+
+ @setfilename myprogram
+
+ into:
+
+ @setfilename myprogram.info
+
+ - Use of Texinfo input files with '.txi' or '.texinfo' extensions
+ is discouraged, and its use will raise warnings in the 'obsolete'
+ category. You are advised to simply use the '.texi' extension
+ instead.
+
+* Documentation fixes:
+
+ - The long-deprecated but still supported two-arguments invocation form
+ of AM_INIT_AUTOMAKE is documented once again. This seems the sanest
+ thing to do, given that support for such an usage might need to remain
+ in place for a unspecified amount of time in order to cater for people
+ who want to define the version number for their package dynamically at
+ configure runtime (unfortunately, Autoconf does not yet support this
+ scenario, so we cannot delegate the work to it).
+
+* Texinfo support:
+
+ - Automake can now be instructed to place '.info' files generated from
+ Texinfo input in the builddir rather than in the srcdir; this is done
+ specifying the new automake option 'info-in-builddir'. This feature
+ was requested by the developers of GCC, GDB, GNU binutils and the GNU
+ bfd library. See the extensive discussion about automake bug#11034
+ for more details.
+
+ - For quite a long time, Automake has been implementing an undocumented
+ hack which ensured that '.info' files which appeared to be cleaned
+ (by e.g. being listed in the CLEANFILES or DISTCLEANFILES variables)
+ were built in the builddir rather than in the srcdir; this hack was
+ introduced to ensure better backward-compatibility with packages such
+ as Texinfo, which did things like:
+
+ info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
+ DISTCLEANFILES = texinfo texinfo-* info*.info*
+ # Do not create info files for distribution.
+ dist-info:
+ @:
+
+ in order not to distribute generated '.info' files.
+
+ Now that we have the 'info-in-builddir' option that explicitly causes
+ generated '.info' files to be placed in the builddir, this hack should
+ be longer necessary, so we deprecate it with runtime warnings. It will
+ likely be removed altogether in Automake 1.14.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.1:
+
* Bugs fixed:
- - Use of the obsolete macro AM_CONFIG_HEADER causes a clear and
- helpful error message, instead of obscure ones (issue introduced
- in Automake 1.13).
+ - Use of the obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC now
+ causes a clear and helpful error message, instead of obscure ones
+ (issue introduced in Automake 1.13).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+New in 1.13:
+
* Bugs fixed:
- ylwrap renames properly header guards in generated header files
-----
-Copyright (C) 1995-2012 Free Software Foundation, Inc.
+Copyright (C) 1995-2013 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
projects / platform / upstream / automake.git / blobdiff