Re: What did AM_ ever do to you?

[Stefano Lattarini]

On 05/01/2013 05:40 AM, Kerrick Staley wrote:
>
> Automake renamed some macros
>
These renames has been done *years* ago.  And they weren't renaming,
really; simply, things that had been implemented in Automake while
Autcoconf was dormant were later moved to their proper place (that is,
the Autoconf codebase); the renames were due to the fact that Automake
uses 'AM_' for the namespace of its macros, while Autoconf uses 'AC_'.

The real problem has been that I've removed the old 'AM_' macros without
a proper deprecation period, erroneously thinking that "they have been
deprecated for so long in the documentation that all projects have surely
stopped using them by now, right?" --- dead wrong I was.

> and dropped support for the older versions
> (AM_CONFIG_HEADER -> AC_CONFIG_HEADERS
>
This had already been reverted in the branch-1.13.2 (you'd have probably
realized this if you had searched the archives before reporting the issue).
I wasn't happy to do this, but the Fedora developers have already applied
a similar change to their Automake, and I'd rather avoid divergences
between upstream Automake and distro-provided Automake if possible.
Now, the use of AM_CONFIG_HEADER will cause a (non-fatal) warning rather
than an hard error.

> and AM_PROG_MKDIR_P -> AC_PROG_MKDIR_P come to mind).
>
I don't follow.  AM_PROG_MKDIR_P has been deprecated, but not removed.
I *tried* to remove it in the master branch, but testing from me and
other people showed that doing so would cause a *lot* of pain with
Gettext integration, so I reverted the removal before it ever hit a
released version.

> This is bad because it breaks every single open source project in
> existence (break ALL the builds),
>
As Diego said, this is an exaggeration that doesn't help your point
(which is mostly valid BTW).

> for reasons
> that most developers don't want to have to think about (writing code is
> fun; worry about how to build it is less fun).
>
> I'm sure there were legitimate technical reasons for the renaming,
>
Yes; see the explanation above about the moving from Automake to Autoconf.

> but I think it would've been better overall if you had kept the deprecated
> namings indefinitely—a little extra work on your part, but much less stress
> for everyone else. Just my 2c worth.
>
In retrospect I mostly agree.  Notice that many of the removed 'AM_' names
(those still used in practice by a non-trivial number of projects) will be
reintroduced in Automake 1.13.2.  Albeit they will trigger non-fatal
deprecation warning, to encourage the developers to update their build
systems to more modern usages and idioms.

Regards,
  Stefano