automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Automake 1.12.1 released


From: Stefano Lattarini
Subject: Re: GNU Automake 1.12.1 released
Date: Thu, 05 Jul 2012 11:26:57 +0200

On 07/05/2012 08:29 AM, tsuna wrote:
> On Fri, Jun 1, 2012 at 9:50 AM, Stefano Lattarini
> <address@hidden> wrote:
>> * Deprecated obsolescent features:
> […]
>>   - The long-obsolete (since 1.10) automake-provided $(mkdir_p) make
>>     variable, @mkdir_p@ configure-time substitution and AM_PROG_MKDIR
>>     m4 macro are deprecated, eliciting a warning in the 'obsolete'
>>     category.  They will be removed in the next major version (1.13).
> 
> What's the right way to portably use mkdir -p then?
>
$(MKDIR_P) in Makefile.am, AC_PROG_MKDIR_P in configure.ac.

> Whether we like it or not, there are still a lot of users out there with
> Automake 1.9.6, which had @mkdir_p@ but not @address@hidden
>
If they want to work on a project that uses the more modern Automake, they
should upgrade then.  Installing Automake from sources is not difficult nor
time consuming.

> I received enough
> complaints from them that 9 months ago I gave up and did a
> s/MKDIR_P/mkdir_p/ on my Makefile.am's.  Now I'm starting to get bug
> reports about $(mkdir_p) expanding to nothing.
>
How so?  Removal of $(mkdir_p) is only planned for Automake 1.13, that is
still unreleased.

> Am I expected to add my own compatibility layer through some
> configure.ac hackery?
>
Basically yes, if you still want to support very old Automakes like 1.9.6.
I suspect in your case, a simple

    AC_SUBST([mkdir_p], ['$(MKDIR_P)'])

should work (untested).

> I wish I could ignore people using obsolete
> software, but there's just too many of them, especially thanks to
> RedHat / CentOS.
> 

HTH,
  Stefano



reply via email to

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