compat: restore AM_PROG_MKDIR, again

OK, this is getting ridiculous, but we cannot remove this macro yet
(and, yes, the fault for this mess lies entirely on me; let's not
dwell on that, thank you very much).

Gettext (so far the greatest "offender" in the use of AM_PROG_MKDIR), in
its latest release 0.18.2, has removed all the uses of that macro still
present in its code base.  So I thought we could finally and safely
remove it.  Wrong.  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.  This has already happened in practice:

  <http://lists.gnu.org/archive/html/bug-grep/2013-01/msg00003.html>

Moreover, while we might see it as not unreasonable to ask a developer
using Automake 1.14 to also update Gettext to 1.18.2, that would not
be enough; in order for gettext to use the correct data files, our
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.  Bad.

So we re-instate this macro as a simple alias for AC_PROG_MKDIR (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).

Note that NEWS is not yet adjusted, since we'll have to adjust it in
maint before (to minimize spurious merge conflicts).

* doc/automake.texi: Update.
* PLANS/obsolete-removed/am-prog-mkdir-p.txt: Likewise.
* t/gettext-macros.sh: Adjust.
* t/am-prog-mkdir-p.sh: New test.
* t/mkdir_p.sh: Remove, folded into the new one.
* t/am-prog-mkdir-p-no-more: Remove as superseded.
* t/list-of-tests.mk: Adjust.
* t/obsolete-err.m4: Re-instate AM_PROG_MKDIR_P as a working
alias for AC_PROG_MKDIR_P (albeit giving runtime warnings, and
calling AC_SUBST on 'mkdir_p' too).
* m4/init.m4 (AM_INIT_AUTOMAKE): No longer call AC_SUBST for
'mkdir_p', as that is once again AM_PROG_MKDIR_P's business.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>

1 files changed, 7 insertions, 65 deletions

diff --git a/PLANS/obsolete-removed/am-prog-mkdir-p.txt b/PLANS/obsolete-removed/am-prog-mkdir-p.txt
index b096ecece..4143fac85 100644
--- a/PLANS/obsolete-removed/am-prog-mkdir-p.txt
+++ b/PLANS/obsolete-removed/am-prog-mkdir-p.txt
@@ -1,67 +1,9 @@
-In Automake 1.13.x
-------------------
+We have dropped any plan to remove the obsolescent macro AM_PROG_MKDIR_P,
+(today just an alias for the Autoconf-provided macro AC_PROG_MKDIR_P), as
+well as the related $(mkdir_p) make variable and the @mkdir_p@ configure
+substitution.
 
-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'.
+That planned removal has already proven source of countless headaches and
+backward-compatibility issues, which vastly outweigh any "clean-up benefit"
+we would get from the removal of that obsolescent but unobtrusive cruft.
 
-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.