D'oh! Sorry. After digging the Autoconf sources (shouldn't
the manual document that @MKDIR_P@ is magic?) I now understand
why my patch was bogus. But I'm not satisfied by the previous
state either. I don't want to causes too much "dominos upgrades"
(where you run Automake 1.10 on your package to discover
that you need another Gettext release).
I'm installing this.
2006-08-20 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* m4/mkdirp.m4 (AM_PROG_MKDIR_P): Prefix mkdir_p with
$(top_builddir)/ if it is a relative directory.
===================================================================
RCS file: /cvs/automake/automake/m4/mkdirp.m4,v
retrieving revision 1.13
diff -u -r1.13 mkdirp.m4
--- m4/mkdirp.m4 19 Aug 2006 15:55:52 -0000 1.13
+++ m4/mkdirp.m4 20 Aug 2006 14:17:50 -0000
@@ -11,9 +11,16 @@
AC_DEFUN([AM_PROG_MKDIR_P],
[AC_PREREQ([2.60])dnl
AC_REQUIRE([AC_PROG_MKDIR_P])dnl
-dnl Automake 1.8 to 1.9.6 used to define mkdir_p.
-dnl We now use MKDIR_P, while keeping a definition of mkdir_p for
-dnl backward compatibility. Do not define mkdir_p as $(MKDIR_P) for
-dnl the sake of Makefile.ins that do not define MKDIR_P.
+dnl Automake 1.8 to 1.9.6 used to define mkdir_p. We now use MKDIR_P,
+dnl while keeping a definition of mkdir_p for backward compatibility.
+dnl @MKDIR_P@ is magic: AC_OUTPUT adjusts its value for each Makefile.
+dnl However we cannot define mkdir_p as $(MKDIR_P) for the sake of
+dnl Makefile.ins that do not define MKDIR_P, so we do our own
+dnl adjustment using top_builddir (which is defined more often than
+dnl MKDIR_P).
AC_SUBST([mkdir_p], ["$MKDIR_P"])dnl
+case $mkdir_p in
+ [\\/$]* | ?:[\\/]*) ;;
+ */*) mkdir_p="\$(top_builddir)/$mkdir_p" ;;
+esac
])
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
