PLANS/obsolete-removed/am-prog-mkdir-p.txt

   1 The macro AM_PROG_MKDIR_P is no longer going to be removed in Automake 1.14
   2 (and in fact, any plan to remove it "evenatually" has been dropped as well).
   3
   4 Let's see a bit of history to understand why.
   5
   6 I had already scheduled the removal of the long-deprecated AM_PROG_MKDR_P
   7 macro (superseded by the Autoconf-provided one AC_PROG_MKDIR_P) for
   8 Automake 1.13 -- see commit 'v1.12-20-g8a1c64f'.
   9
  10 Alas, it turned out the latest Gettext version at the time (0.18.1.1) was
  11 still using that macro:
  12
  13   <http://lists.gnu.org/archive/html/automake/2012-09/msg00010.html>
  14
  15 And since the maintenance of Gettext was stalled, I couldn't get a fix
  16 committed and released in time for the appearance of Automake 1.13:
  17
  18   <http://lists.gnu.org/archive/html/bug-gettext/2012-04/msg00018.html>
  19   <http://lists.gnu.org/archive/html/bug-gettext/2012-06/msg00012.html>
  20   <http://lists.gnu.org/archive/html/bug-gettext/2012-10/msg00001.html>
  21
  22 So, on strong advice by Jim Meyering, in commit 'v1.12.4-158-gdf23daf'
  23 I re-introduced AM_PROG_MKDIR_P in Automake (thanks to Jim for having
  24 convinced me to do so in time!)
  25
  26 But then, Gettext (as said, the greatest "offender" in the use of
  27 AM_PROG_MKDIR_P), in its latest release 0.18.2, finally removed all the
  28 uses of that macro still present in its code base.  Yay.  So I thought
  29 we could finally and quite safely remove AM_PROG_MKDIR_P in Automake 1.14;
  30 and I proceeded to do so, see commit 'v1.13-30-gd01834b' and the merge
  31 commit 'v1.13-5-gb373ad9'.  Well, it turned out I was wrong, again, and
  32 in a trickier and sublter way this time.  Let's see the details.
  33
  34 If a package's 'configure.ac' contains a call like:
  35
  36     AM_GNU_GETTEXT_VERSION([0.18])
  37
  38 then the 'autopoint' script will bring the data files from the Gettext
  39 release *1.18* into the package's tree -- yes, even even if the developer
  40 has installed *and is using* Gettext 1.18.2!  Now, these data files
  41 comprise m4 files (that will be seen by subsequent aclocal and autoconf
  42 calls), and of course, the pre-0.18.2 version of some of these files
  43 still contains occurrences of AM_PROG_MKDIR_P -- so Automake 1.13 errors
  44 out, and we lose.  That already happened in practice:
  45
  46     <http://lists.gnu.org/archive/html/bug-grep/2013-01/msg00003.html>
  47
  48 Moreover, while I might see it as not unreasonable to ask a developer
  49 using Automake 1.14 to also update Gettext to 1.18.2, that would not
  50 be enough; in order for gettext to use the correct data files, that
  51 developer would have to update his configure.ac to read:
  52
  53     AM_GNU_GETTEXT_VERSION([0.18.2])
  54
  55 thus requiring *all* of his co-developers to install Gettext 1.18.2,
  56 even if they are still using, say, Automake 1.13.  Bad.
  57
  58 So I decided to re-instate this macro as a simple alias for AC_PROG_MKDIR_P
  59 (plus a non-fatal runtime warning in the 'obsolete' category), and drop
  60 any plan to remove it (see how much good those plans have done us so far).
  61 See commit v1.13.1-109-g030ecb4.
  62
  63 Similarly, the obsolete '@mkdir_p@' substitution and '$(mkdir_p)' make
  64 variable are still supported, as simple aliases to '$(MKDIR_P)'.