bug#26100: Switch from Automake to GNU Make

[Paul Eggert <eggert@cs.ucla.edu>]

Glenn Morris wrote:

>
> autogen.sh passes "-f" to autoreconf, so the new version will be more
> aggressive about updating than the old version was.

True. However, in practice this is typically what we want, I think, for the 
reason mentioned in autogen.sh: if autoreconf itself has changed, we want its 
new and not its old output. In the old days when the files were 
sort-of-maintained by hand it made sense to avoid -f, but now that we almost 
always update them automatically it's better to let the robots go to town.

>(Also, this hunk
> isn't directly related to the overall change, is it?)

It is related, because autogen.sh now does more than invoke autoreconf: it also 
creates an up-to-date aclocal.m4 (something autoreconf no longer does).

>> -  autoreconf -fi -I m4 || exit $?
>> +  autoreconf -fi -I m4 || exit
>
> Also unrelated?

Yes, that's merely a minor cleanup, as "exit $?" is equivalent to "exit" and 
it's a bit weird to use the unusual long form (it distracts the reader; at 
least, it distracted me).

> It's a tiny bit disappointing that we need to version these again
> (you removed them in 2011).

Yes, the extra files are disappointing. However, it's not as bad as it appears, 
for three reasons.

1. These files are automatically generated by admin/merge-gnulib so they are 
easy to maintain. Come to think of it, if we could ever get "admin/merge-gnulib" 
to be part of the autogen.sh procedure, we could stop versioning these files again.

2. The old way of automatically-generating these files meant that their contents 
depended on the vagaries of which version of Automake was used by the 
distribution's builder, which meant that Emacs releases sometimes inadvertently 
contained obsolete versions of these files. In contrast, the new approach means 
all distribution builders use the same version of these files.

3. In practice the recent Gnulib copy of these files tends to be more up-to-date 
than the luck-of-the-builder-draw Automake copy, so we'll tend to be more 
up-to-date when doing developer builds.

> (I wonder why autoconf doesn't come with these files?)

They were originally developed for other packages and still "belong" to them. 
One package (config) predates Autoconf and its maintainer wants to stay 
independent. The install-sh file comes from Automake; I suppose it could be 
moved to Autoconf but it's low priority (partly as Automake maintenance has 
essentially stopped....).