diff options
Diffstat (limited to 'PLANS')
| -rw-r--r-- | PLANS/README | 25 | ||||
| -rw-r--r-- | PLANS/obsolete-removed/am-prog-mkdir-p.txt | 62 | ||||
| -rw-r--r-- | PLANS/obsolete-removed/configure.in.txt | 28 | ||||
| -rw-r--r-- | PLANS/rm-f-without-args.txt | 40 | ||||
| -rw-r--r-- | PLANS/subdir-objects.txt | 62 | ||||
| -rw-r--r-- | PLANS/texi/drop-split-info-files.txt | 27 | ||||
| -rw-r--r-- | PLANS/texi/warnings-for-automake-ng-compatibility.txt | 21 |
7 files changed, 265 insertions, 0 deletions
diff --git a/PLANS/README b/PLANS/README new file mode 100644 index 000000000..87cb8dc36 --- /dev/null +++ b/PLANS/README @@ -0,0 +1,25 @@ +"Plans" for future or on-going Automake development. + +The contents is meant to help ensure a more controlled and smooth +development and evolution for Automake, in several ways. + + - Having the plans clearly spelled out should will avoid messy + roadmaps with no clear way forward or with muddy or ill-defined + aims or purposes; a trap this is too easy to fall into. + + - Keeping planned changes cooking and re-hashed for a while should + ensure rough edges are smoothed up, transitions are planned in a + proper way (hopefully avoiding debacles like the AM_MKDIR_PROG_P + deprecation and the AM_CONFIG_HEADER too-abrupt removal), and + "power users" have more chances of getting informed in due time, + thus having all the time to prepare for the changes or raise + objections against them. + + - Having the plans clearly stated and registered in a "centralized" + location should make it more difficult to them to slip through + the cracks, getting forgotten or (worse) only half-implemented. + + - Even for discussions and plans registered on the Bug Tracker + as well, a corresponding entry in the PLANS directory can help + in keeping main ideas summarized, and consensus and/or objections + registered and easily compared. 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 000000000..20d5cf52c --- /dev/null +++ b/PLANS/obsolete-removed/am-prog-mkdir-p.txt @@ -0,0 +1,62 @@ +The macro AM_PROG_MKDIR_P is no longer going to be removed from Automake. +Let's see a bit of history to understand why. + +I 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, I 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 strong advice by Jim Meyering, in commit 'v1.12.4-158-gdf23daf' +I re-introduced AM_PROG_MKDIR_P in Automake (thanks to Jim for having +convinced me to do so in time!) + +But then, Gettext (as said, the greatest "offender" in the use of +AM_PROG_MKDIR_P), in its latest release 0.18.2, finally removed all the +uses of that macro still present in its code base. Yay. So I thought +we could finally and quite safely remove AM_PROG_MKDIR_P in Automake 1.14; +and I proceeded to do so, see commit 'v1.13-30-gd01834b' and the merge +commit 'v1.13-5-gb373ad9'. Well, it turned out I was wrong, again, and +in a trickier and sublter way this time. Let's see the details. + +If a package's 'configure.ac' contains a call like: + + AM_GNU_GETTEXT_VERSION([0.18]) + +then the 'autopoint' script will bring the data files from the Gettext +release *1.18* into the package's tree -- yes, even even if the developer +has installed *and is using* Gettext 1.18.2! Now, these data files +comprise m4 files (that will be seen by subsequent aclocal and autoconf +calls), and of course, the pre-0.18.2 version of some of these files +still contains occurrences of AM_PROG_MKDIR_P -- so Automake 1.13 errors +out, and we lose. That already happened in practice: + + <http://lists.gnu.org/archive/html/bug-grep/2013-01/msg00003.html> + +Moreover, while I might see it as not unreasonable to ask a developer +using Automake 2.0 to also update Gettext to 1.18.2, that would not +be enough; in order for gettext to use the correct data files, that +developer would have to update his configure.ac to read: + + AM_GNU_GETTEXT_VERSION([0.18.2]) + +thus requiring *all* of his co-developers to install Gettext 1.18.2, +even if they are still using, say, Automake 1.13 or 1.14. Bad. + +So I decided to re-instate this macro as a simple alias for AC_PROG_MKDIR_P +(plus a non-fatal runtime warning in the 'obsolete' category), and drop +any plan to remove it (see how much good those plans have done us so far). +See commit v1.13.1-109-g030ecb4. + +Similarly, the obsolete '@mkdir_p@' substitution and '$(mkdir_p)' make +variable are still supported, as simple aliases to '$(MKDIR_P)'. diff --git a/PLANS/obsolete-removed/configure.in.txt b/PLANS/obsolete-removed/configure.in.txt new file mode 100644 index 000000000..d3f6da795 --- /dev/null +++ b/PLANS/obsolete-removed/configure.in.txt @@ -0,0 +1,28 @@ +In Automake 1.13.x (once planned, then dropped) +----------------------------------------------- + +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 2.0 +---------------- + +... 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 2.0 (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 2.0 is released. + +Note that the removal of 'configure.in' has already been implemented +in our 'master' branch (from where the 2.0 release will be finally +cut); see commits 'v1.13-17-gbff57c8' and 'v1.13-21-g7626e63'. diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt new file mode 100644 index 000000000..b940fc3e9 --- /dev/null +++ b/PLANS/rm-f-without-args.txt @@ -0,0 +1,40 @@ +Summary +------- + +POSIX will say in a future version that calling "rm -f" with no argument +is OK; and this sensible behaviour seem to be already very widespread in +"the wild" (and possibly lacking only on those systems that are well on +their way to obsolescence). + +Se we'd like to simplify several automake-generated "cleaning" rules +accordingly, to get rid of the awful idiom: + + test -z "$(VAR)" || rm -f $(VAR) + +See automake bug#10828. + +For Automake 1.14 (DONE) +------------------------ + +Add a temporary "probe check" in AM_INIT_AUTOMAKE that verifies that +the no-args "rm -f" usage is supported on the system configure is +being run on; complain loudly if this is not the case, and tell the +user to report the situation to us. + +For Automake 2.0 +---------------- + +Make any failure in the configure-time probe check introduced by the +previous point fatal; and in case of failure, also suggest to the user +to install an older version of GNU coreutils to work around the +limitation of his system (this version should be old enough not to +be bootstrapped with Automake 2.0, otherwise the user will face a +bootstrapping catch-22). + +In all our recipes, start assuming "rm -f" with no argument is OK; +simplify and de-uglify the recipes accordingly. + +For Automake 3.0 +---------------- + +Remove the runtime probe altogether. diff --git a/PLANS/subdir-objects.txt b/PLANS/subdir-objects.txt new file mode 100644 index 000000000..94c6305ec --- /dev/null +++ b/PLANS/subdir-objects.txt @@ -0,0 +1,62 @@ +Summary +------- + +We want to make the behaviour currently enabled by the 'subdir-objects' +the default one, and in fact the *only* one, in Automake 2.0. +See automake bug#13378: <http://debbugs.gnu.org/13378>. + +Details +------- + +The fact that Automake-generated Makefiles place compiled object files in +the current directory by default, also when the corresponding source file +is in a subdirectory, is basically an historical accident, due to the fact +that the 'subdir-objects' option had only been introduced in April 1999, +starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never +made the default (likely to avoid backwards-compatibility issues). + +Since I believe the behaviour enabled by the 'subdir-objects' is the most +useful one, and in fact the *only* natural one, I'd like to make it the +only one available, simplifying the Automake implementation and APIs a +little in the process. + +Alas, since this also means changing the default behaviour of Automake +('subdir-objects' is not enabled by default, sadly), this means the +transition path will be less smooth than I'd like. + +DONE for automake 1.13.2 +------------------------ + +The bug spotted by Nick Bowler: + + <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35> + <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44> + +and exposed in test case 't/ccnoco4.sh' has been fixed (see commit +v1.13.1-56-g34001a9). The bug was due to the fact that Automake-generated +C compilation rules mistakenly passed the "-c -o" options combination +unconditionally (even to losing compiler) when the 'subdir-objects' was +used but sources were only present in the top-level directory. + +DONE for automake 1.14 +---------------------- + +We give a warning in the category 'unsupported' if the 'subdir-objects' +option is not specified. This should give the users enough forewarning +about the planned change, and give them time to update their packages +to the new semantic. + +We also make sure to avoid the warning when it would be irrelevant, i.e., +if all source files sit in "current" directory (thanks to Peter Johansson +for suggesting this). + +For automake 2.0 +---------------- + +Make the behaviour once activated by the 'subdir-object' option mandatory. +With that change, we'll drop support for the "old" behaviour of having +object files derived from sources in a subdirectory being placed in the +current directory rather than in that same subdirectory. + +Still keep the 'subdir-objects' option supported (as a simple no-op +now), to save useless churn in our user's build systems. diff --git a/PLANS/texi/drop-split-info-files.txt b/PLANS/texi/drop-split-info-files.txt new file mode 100644 index 000000000..a0a5636e7 --- /dev/null +++ b/PLANS/texi/drop-split-info-files.txt @@ -0,0 +1,27 @@ +For in Automake 2.0 (DONE) +-------------------------- + +We will drop split info files in Automake 2.0. +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. 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 000000000..aca46b4a2 --- /dev/null +++ b/PLANS/texi/warnings-for-automake-ng-compatibility.txt @@ -0,0 +1,21 @@ +Done in 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). |