On 07/05/2012 11:56 PM, tsuna wrote:
> On Thu, Jul 5, 2012 at 2:26 AM, Stefano Lattarini
> <stefano.lattar...@gmail.com> wrote:
>> 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 agree. But the fact is that there are hundreds of organizations out
> there that build stuff on CentOS and RedHat, which generally come with
> severely obsolete autotools, and it's already creating an unnecessary
> support burden on package maintainers like me, and removing mkdir_p is
> just going to add more to that. I've been telling people to upgrade
> repeatedly for months, but eventually decided to try to make my users'
> life easier (and mine too, from a support perspective) by doing what I
> can on my end to minimize incompatibilities.
>
> What are we gaining by removing mkdir_p? Sure it's obsolete, but why
> remove it? Especially when it takes some popular distros around 10
> years to ship more recent software.
>
Well, the real "complexity" was coming from the AM_PROG_MKDIR_P macro,
so I guess keeping on supporting $(mkdir_p) for one more year or so
would cost us basically nothing -- that is, assuming that something
like:
mkdir_p = $(MKDIR_P)
in the generated Makefiles is enough. If you can confirm this works
for your use cases, I'm willing to do the change.
> Don't get me wrong, I'm always trying to fight legacy stuff and get
> rid of obsolete cruft. But autotools have a real issue thanks to many
> distributions and organizations that live in the past.
>
>> How so? Removal of $(mkdir_p) is only planned for Automake 1.13, that is
>> still unreleased.
>
> I don't know how exactly yet, but I got a report from a 1.12.1 user
> where the Makefile generated by Automake didn't have a definition for
> `mkdir_p'.
>
Regards,
Stefano
