--- /dev/null
+In Automake 1.13.x
+------------------
+
+We had already scheduled the removal of the long-deprecated AM_PROG_MKDR_P
+macro (superseded by the autoconf-provided one AC_PROG_MKDIR_P) for
+Automake 1.13 -- see commit 'v1.12-20-g8a1c64f'.
+
+Alas, it turned out the latest Gettext version at the time (0.18.1.1) was
+still using that macro:
+
+ <http://lists.gnu.org/archive/html/automake/2012-09/msg00010.html>
+
+And since the maintenance of Gettext was stalled, we couldn't get a fix
+committed and released in time for the appearance of automake 1.13:
+
+ <http://lists.gnu.org/archive/html/bug-gettext/2012-04/msg00018.html>
+ <http://lists.gnu.org/archive/html/bug-gettext/2012-06/msg00012.html>
+ <http://lists.gnu.org/archive/html/bug-gettext/2012-10/msg00001.html>
+
+So, on a strong advice by Jim Meyering, in commit 'v1.12.4-158-gdf23daf'
+we re-introduced AM_PROG_MKDIR_P in Automake. That has been an
+unfortunate necessity (thanks to Jim for having convinced me of that in
+time!)
+
+
+For Automake 1.14
+-----------------
+
+Finally, AM_PROG_MKDR_P we'll be fully obsolete in in Automake 1.14 (see
+commit 'v1.12.4-174-g5a28948', merged in master by 'v1.13-5-gb373ad9'),
+while still offering a clear error message for the moment (see follow-up
+commit 'v1.13-30-gd01834b').
+
+We can finally do so because Gettext has got a maintainer in the meantime,
+and a new release has been made that no longer uses AM_PROG_MKDIR_P:
+
+ <http://lists.gnu.org/archive/html/bug-gettext/2012-12/msg00064.html>
+
+We still keep the obsolete '@mkdir_p@' substitution and '$(mkdir_p)'
+variable around though, since they are still used by 'Makefile.in.in'
+template from gettext:
+
+ $ cd ~/src/gettext
+ $ git checkout master
+ $ git describe
+ v0.18.2-4-g3188bbf
+ $ grep mkdir_p gettext-runtime/po/Makefile.in.in | grep -v '^#'
+ mkdir_p = @mkdir_p@
+ $(mkdir_p) $(DESTDIR)$(gettextsrcdir); \
+ $(mkdir_p) $(DESTDIR)$$dir; \
+ $(mkdir_p) $(DESTDIR)$(gettextsrcdir); \
+ $(mkdir_p) $(DESTDIR)$$dir; \
+
+(see also Automake commit v1.12.1-112-g2551021).
+
+More to the point, it's almost impossible to diagnose usages of those
+macro and substitution using the existing Automake parsing and warning
+infrastructure; it's much easier to just keep them around for a while.
+
+
+The future
+----------
+
+We want to finally remove '@mkdir_p@' and '$(mkdir_p)' as well some
+day. It would be nice if we could do so with some kind of deprecation,
+but that is not worth too much work. Anyway, no hurry an no high
+priority for this removal.
--- /dev/null
+In Automake 1.13.x
+------------------
+
+We are already warning about 'configure.in' used as the name for the
+Autoconf input file ('configure.ac' should be used instead); we've
+been doing that since Automake 1.12.4.
+
+We had scheduled to remove support for it altogether in Automake 1.13
+(and announced that in our NEWS file), because we thought that Autoconf
+too would have started deprecating it by the time our 1.13 release was
+done. Alas, this hasn't been the case: the deprecation code is only
+present in the development version of autoconf so far (scheduled to
+become Autoconf 2.70). So ...
+
+
+For Automake 1.14
+-----------------
+
+... we have decided to wait until 2.70 is out before really removing
+'configure.in' support. Since we plan to require Autoconf 2.70 in
+Automake 1.14 (so that we can remove the hacky code emulating
+AC_CONFIG_MACRO_DIRS for older autoconf versions), we are quite sure
+that Autoconf will actually have started deprecating 'configure.in'
+by the time Automake 1.14 is released.
+
+Note that the removal of 'configure.in' has already been implemented
+in our master branch (from where the 1.14 release will be finally
+cut); see commits 'v1.13-17-gbff57c8' and 'v1.13-21-g7626e63'.
--- /dev/null
+For automake 1.14
+-----------------
+
+We want to drop split info files in Automake 1.14.
+See automake bug#13351: <http://debbugs.gnu.org/13351>.
+
+Basically, it has been confirmed that the original reason behind
+the existence of split info files was indeed "efficiency,
+especially memory size":
+<http://lists.gnu.org/archive/html/texinfo-devel/2012-08/msg00024.html>
+
+So split info files have lost their reason d'etre on modern systems
+(where even Emacs has become a lightweight program ;-). And you are
+not using an embedded system to read Info documentation, right?
+
+In addition, it appears that the use of split info files (at least
+the way Automake-generated rules have been handling them for a long
+time) can cause real problems in some (admittedly quite corner-case)
+situations; see automake bug#12320: <http://debbugs.gnu.org/12320>.
+
+This change should be completely transparent to the developer (no
+adjustments needed to be made to Makefile.am or other parts of the
+build system). In case some CI system or overly picky build script
+used to rely on that feature, they'll have to be adjusted; but that
+is expected to be a rare occurrence, and thus a price worth pay for
+the nice simplifications and the fixlets this planned change will
+offer us.
--- /dev/null
+For automake 1.13.2:
+--------------------
+
+I have discouraged the use of '.txi' and '.texinfo' suffixes for
+Texinfo inputs (see commit 'v1.13.1-6-ge1ed314') and the generation
+of suffix-less info files (commit 'v1.13.1-4-g2af418d').
+
+This is done to ease transition to Automake-NG (see commits
+'v1.12.1-416-gd5459b9' and 'v1.12.1-392-ga0c7b6a' there), and
+(to a lesser degree) to discourage use of seldom-tested setups.
+
+
+The Future:
+-----------
+
+I have no plans to do the further step of removing support for those
+usages in future Automake versions. That would be a gratuitous
+incompatibility (in Automake-NG, they have been useful because have
+allowed further refactorings and improvements, but those were
+based on GNU make features, and as such have no place in mainline
+Automake).
projects / platform / upstream / automake.git / commitdiff