From: Stefano Lattarini Date: Fri, 4 Jan 2013 10:48:33 +0000 (+0100) Subject: plans: add some on-going plans (already registered on the bug tracker) X-Git-Tag: v1.13b~139^2 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=0071e0155c0881ef7cafd7b8f9a796e8377fc6db;p=platform%2Fupstream%2Fautomake.git plans: add some on-going plans (already registered on the bug tracker) Signed-off-by: Stefano Lattarini --- diff --git a/PLANS/obsolete-removed/am-prog-mkdir-p.txt b/PLANS/obsolete-removed/am-prog-mkdir-p.txt new file mode 100644 index 0000000..b096ece --- /dev/null +++ b/PLANS/obsolete-removed/am-prog-mkdir-p.txt @@ -0,0 +1,67 @@ +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: + + + +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: + + + + + +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: + + + +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. diff --git a/PLANS/obsolete-removed/configure.in.txt b/PLANS/obsolete-removed/configure.in.txt new file mode 100644 index 0000000..baed853 --- /dev/null +++ b/PLANS/obsolete-removed/configure.in.txt @@ -0,0 +1,28 @@ +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'. diff --git a/PLANS/texi/drop-split-info-files.txt b/PLANS/texi/drop-split-info-files.txt new file mode 100644 index 0000000..7084331 --- /dev/null +++ b/PLANS/texi/drop-split-info-files.txt @@ -0,0 +1,27 @@ +For automake 1.14 +----------------- + +We want to drop split info files in Automake 1.14. +See automake bug#13351: . + +Basically, it has been confirmed that the original reason behind +the existence of split info files was indeed "efficiency, +especially memory size": + + +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: . + +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. diff --git a/PLANS/texi/warnings-for-automake-ng-compatibility.txt b/PLANS/texi/warnings-for-automake-ng-compatibility.txt new file mode 100644 index 0000000..1dd3da3 --- /dev/null +++ b/PLANS/texi/warnings-for-automake-ng-compatibility.txt @@ -0,0 +1,21 @@ +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).