[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AM_PROG_MKDIR_P: too soon to obsolete this macro?
From: |
Stefano Lattarini |
Subject: |
Re: AM_PROG_MKDIR_P: too soon to obsolete this macro? |
Date: |
Wed, 12 Sep 2012 21:13:30 +0200 |
On 09/12/2012 06:04 PM, Jim Meyering wrote:
> I see that gettext (latest from git) still AC_REQUIRE's
> AM_PROG_MKDIR_P from its intl.m4 and po.m4 files, which
> are pulled into *many* projects.
>
I know. I sent a patch several months ago to gettext to fix that issue:
<http://lists.gnu.org/archive/html/bug-gettext/2012-04/msg00018.html>
and other peoples have reported the problem as well:
<http://lists.gnu.org/archive/html/bug-gettext/2012-06/msg00012.html>
but no answer/feedback has come.
If gettext doesn't fix the issue, projects using it will have to put a
workaround in place themselves, like adding an AM_PROG_MKDIR_P definition
(simply as an alias to AC_PROG_MKDIR_P) in a local '.m4' file. Sorry.
> When I try to build one of those projects (coreutils) using the latest
> from automake.git/master, I see this failure:
>
> $ aclocal -I m4
> configure.ac:477: warning: AM_PROG_MKDIR_P is m4_require'd but not
> m4_defun'd
> m4/po.m4:23: AM_PO_SUBDIRS is expanded from...
> m4/gettext.m4:57: AM_GNU_GETTEXT is expanded from...
> configure.ac:477: the top level
>
> That is because AM_PROG_MKDIR_P is marked to become obsolete
> in the next release of automake.
>
> I would have noticed sooner, but a few months ago, I worked
> around this by installing a private fix in the --prefix=/p hierarchy
> where I install personal copies of tools like this, then forgot to
> report it.
>
> Today I built using the latest automake on a new system
> (without that manual patch) and re-diagnosed the problem.
>
Regards,
Stefano