[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gettext: prepare Makefile.in.in for next Automake version
From: |
Alexandre Duret-Lutz |
Subject: |
Re: gettext: prepare Makefile.in.in for next Automake version |
Date: |
Wed, 06 Sep 2006 13:31:54 +0200 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux) |
>>> "RW" == Ralf Wildenhues <address@hidden> writes:
[...]
RW> While I understand this, I do think your change is unfortunate:
RW> First, it require Autoconf to always use `mkdir' with an absolute
RW> directory. This is neither documented nor is it a desirable situation:
RW> http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00052.html
RW> but it ended up being part of Autoconf for simplicity of the code (or
RW> maybe just by chance?):
RW> http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00142.html
We could change Automake's
case $mkdir_p in
[\\/$]* | ?:[\\/]*) ;;
*/*) mkdir_p="\$(top_builddir)/$mkdir_p" ;;
esac
into
case $mkdir_p in
[\\/$]* | ?:[\\/]*) ;;
*/install-sh*) mkdir_p="\$(top_builddir)/$mkdir_p" ;;
esac
RW> In hindsight, it may have been easier to just have AC_PROG_MKDIR_P use
RW> the mkdir_p variable; but back then we weren't sure whether Automake
RW> would adopt it quickly, or incompatibilities could develop:
RW> http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00034.html
RW> Oh well. A bit of a mess.
I'm starting to wonder why we switched to this macro, and
whether it wouldn't be wiser to revert all these changes back to
the original AM_PROG_MKDIR_P. It seems the switch to
AC_PROG_MKDIR_P only brought us trouble, and no improvement :(
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: gettext: prepare Makefile.in.in for next Automake version,
Alexandre Duret-Lutz <=