[Top][All Lists]

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

bug#26100: Switch from Automake to GNU Make

From: Paul Eggert
Subject: bug#26100: Switch from Automake to GNU Make
Date: Thu, 16 Mar 2017 02:22:36 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

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....).

reply via email to

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