automake
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]