-New in 1.13.2:
+* WARNING: New versioning scheme for Automake.
+
+ - Starting with this version onward, Automake will use an update and
+ more rational versioning scheme, one that will allow users to know
+ which kind of changes can be expected from a new version, based on
+ its version number.
+
+ + Micro versions (e.g., 1.13.3, 2.0.1, 3.2.8) will introduce only
+ documentation updates and bug and regression fixes; they will
+ not introduce new features, nor any backward-incompatibility (any
+ such incompatibility would be considered a bug, to be fixed with
+ a further micro release).
+
+ + Minor versions (e.g., 1.14, 2.1) can introduce new backward
+ compatible features; the only backward-incompatibilities allowed
+ in such a release are new *non-fatal* deprecations and warnings,
+ and possibly fixes for old or non-trivial bugs (or even inefficient
+ behaviours) that could unfortunately have been seen, and used, by
+ some developers as "corner case features". This kind of fixes
+ should hopefully be quite rare.
+
+ + Major versions (now expected to be released every 18 or 24 months,
+ and not more often) can introduce new big features (possibly with
+ rough edges and not-fully-stabilized APIs), removal of deprecated
+ features, backward-incompatible changes of behaviour, and possibly
+ major refactorings (that, while ideally transparent to the user,
+ could introduce new bugs). Incompatibilities should however not
+ be introduced gratuitously and abruptly; a proper deprecation path
+ should be duly implemented in the preceding minor releases.
+
+ - According to this new scheme, the next major version of Automake
+ (the one that has until now been labelled as '1.14') will actually
+ become "Automake 2.0". Automake 1.14 will be the next minor version,
+ which will introduce new features and deprecation, but no backward
+ incompatibility.
+
+ - See discussion about automake bug#13578 for more details and
+ background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
* WARNING: Future backward-incompatibilities!
- - Automake 1.14 will require Autoconf 2.70 or later (which is still
+ - Automake 2.0 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).
+ before Automake 2.0 is).
- - Automake 1.14 will drop support for the long-deprecated 'configure.in'
- name for the Autoconf input file. You are advised to start using
+ - Automake 2.0 will drop support for the long-deprecated 'configure.in'
+ name for the Autoconf input file. You are advised to start using the
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
- @mkdir_p@ substitution will still remain available (as aliases of
- $(MKDIR_P)) for the moment, for better backward compatibility; but
- you are advised to stop using ASAP.
-
- The ACLOCAL_AMFLAGS special make variable will be fully deprecated
- in Automake 1.14 (where it will raise warnings in the "obsolete"
+ in Automake 2.0 (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 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
- is expected to retire support from them in December 2013; see
- <http://www.sgi.com/services/support/irix_mips_support.html> for
- more information.
+ - Automake 2.0 will remove support for automatic dependency tracking
+ with the SGI C/C++ compilers on IRIX. The SGI depmode has been
+ reported broken "in the wild" already, and we don't think investing
+ time in debugging and fixing is worthwhile, especially considering
+ that SGI has last updated those compilers in 2006, and is expected
+ to retire support for them in December 2013:
+ <http://www.sgi.com/services/support/irix_mips_support.html>
- Future versions of Automake might remove support for MS-DOS and
Windows 95/98/ME (support for them was offered by relying on the
DJGPP project). Note however that both Cygwin and MSYS/MinGW on
modern Windows versions will continue to be fully supported.
- - Support for the long-deprecated INCLUDES variable will be removed
- altogether in Automake 1.14. The AM_CPPFLAGS variable should be
- used instead.
-
- Automake-provided scripts and makefile recipes might (finally!)
- start assuming a POSIX shell in Automake 1.14.
+ start assuming a POSIX shell in Automake 2.0.
- - Starting from Automake 1.14, third-party m4 files located in the
+ - Starting from Automake 2.0, third-party m4 files located in the
system-wide aclocal directory, as well as in any directory listed
in the ACLOCAL_PATH environment variable, will take precedence
over "built-in" Automake macros. For example (assuming Automake
is installed in the /usr/local hierarchy), a definition of the
AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
should take precedence over the same-named automake-provided macro
- (defined in '/usr/local/share/aclocal-1.14/vala.m4').
+ (defined in '/usr/local/share/aclocal-2.0/vala.m4').
-* 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.
+New in 1.13.2:
- - 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.
+* 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.
+
+* 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.2:
* Documentation fixes:
configure runtime (unfortunately, Autoconf does not yet support this
scenario, so we cannot delegate the work to it).
+ - The serial testsuite harness is no longer reported as "deprecated",
+ but as "discouraged". We have no plan to remove it, not to make its
+ use cause runtime warnings.
+
+ - The parallel testsuite is no longer reported as "experimental"; it
+ is well tested, and should be stable now.
+
+ - The 'shar' and 'tarZ' distribution formats and the 'dist-shar' and
+ 'dist-tarZ' options are obsolescent, and their use is deprecated
+ in the documentation.
+
+ - Other minor miscellaneous fixes and improvements; in particular,
+ some improvements in cross-references.
+
+* 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.
+
+* Bugs fixed:
+
+ - The obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC work once
+ again, as they did in Automake 1.12.x (albeit printing runtime
+ warnings in the 'obsolete' category). Removing them has turned
+ out to be a very bad idea, because it complicated distro packing
+ enormously. Making them issue fatal warnings, as we did in
+ Automake 1.13, has turned out to be a similarly very bad idea,
+ for exactly the same reason.
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.1: