-The macro AM_PROG_MKDIR_P is no longer going to be removed in Automake 1.14
-(and in fact, any plan to remove it "evenatually" has been dropped as well).
+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.
-Let's see a bit of history to understand why.
+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.
+
++-*-*-*-
++
++Let's see a bit of history.
+
+ 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 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, 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. 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)'.
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
- dnl TODO: Remove in Automake 1.15.
+AC_DEFUN([AM_PROG_MKDIR_P],
+[AC_REQUIRE([AC_PROG_MKDIR_P])dnl
+AC_SUBST([mkdir_p], ['$(MKDIR_P)'])dnl
+AC_DIAGNOSE([obsolete],
+[macro '$0' is deprecated.
+You should use the Autoconf-provided 'AC][_PROG_MKDIR_P' macro instead,
+and use '$(MKDIR_P)' instead of '$(mkdir_p)' in your Makefile.am files.])])
+
AC_DEFUN([AM_CONFIG_HEADER],
- [AC_FATAL(['$0': this macro is obsolete.
- You should use the 'AC][_CONFIG_HEADERS' macro instead.])])
+ [AC_DIAGNOSE([obsolete],
+ ['$0': this macro is obsolete.
+ You should use the 'AC][_CONFIG_HEADERS' macro instead.])dnl
+ AC_CONFIG_HEADERS($@)])
- dnl TODO: Remove in Automake 1.15.
AC_DEFUN([AM_PROG_CC_STDC],
- [AC_FATAL(['$0': this macro is obsolete.
- You should simply use the 'AC][_PROG_CC' macro instead.
- Also, your code should no longer depend upon 'am_cv_prog_cc_stdc',
- but upon 'ac_cv_prog_cc_stdc'.])])
+ [AC_PROG_CC
+ am_cv_prog_cc_stdc=$ac_cv_prog_cc_stdc
+ AC_DIAGNOSE([obsolete],
+ ['$0': this macro is obsolete.
+ You should simply use the 'AC][_PROG_CC' macro instead.
+ Also, your code should no longer depend upon 'am_cv_prog_cc_stdc',
+ but upon 'ac_cv_prog_cc_stdc'.])])
- dnl TODO: Remove in Automake 1.14.
AC_DEFUN([AM_C_PROTOTYPES],
[AC_FATAL([automatic de-ANSI-fication support has been removed])])
AU_DEFUN([fp_C_PROTOTYPES], [AM_C_PROTOTYPES])
projects / thirdparty / automake.git / commitdiff
