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

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