an update to automake-1.11?

[Jim Meyering]

Mark McLoughlin wrote:
> On Wed, 2009-07-01 at 12:50 +0200, Ondřej Vašík wrote:
>> Mark McLoughlin wrote:
>> > On Wed, 2009-07-01 at 09:02 +0200, Ondřej Vašík wrote:
>> > > Owen Taylor wrote:
>> > > > I was rather surprised to see:
>> > > >
>> > > >  https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661
>> > > >  https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076
>> > > >  https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370
>> > > >
>> > > > Where the automake was upgraded to 1.11 for F9, F10, and F11.
>> > >
>> > > Upgrade on F-11 (and F-10) was requested because there are some projects
>> > > (like gnulib/coreutils) which really need automake 1.11 for build in
>> > > latest stable versions.
>> >
>> > Is there a bug report with details of this gnulib/coreutils request?
>>
>> Not really, it was just direct irl/irc/mail communication with
>> automake/autoconf fedora maintainers&comaintainers. First request was
>> only about 1.10b in rawhide (after f-12 split) - as I needed at least
>> 1.10b to build coreutils-7.4 there (otherwise only with an ugly hack).
>
> Okay, but what exactly are we talking about here? What does gnulib or
> coreutils need that 1.10 doesn't have?

Hi Mark,

I think it's great that automake-1.11 made it into F11 and F10.
Even for F9, it's seems worthwhile.

The features in automake-1.11 that I've found worthwhile
(in addition to 3 years worth of improved robustness,
portability and performance, fewer bugs, etc.)
are enabled by these two lines from coreutils' configure.ac:

  AM_INIT_AUTOMAKE([1.11 dist-xz color-tests parallel-tests])
  AM_SILENT_RULES([yes])

The silent-rules option makes it so build output by default
no longer includes many compile/link/etc command invocations.
Instead, you get very brief lines like these:

  ...
  CC     tee.o
  CC     test.o
  CC     timeout.o
  CC     true.o
  CC     truncate.o
  CC     tty.o
  CC     whoami.o
  CC     yes.o
  CC     base64.o
  CC     setuidgid.o
  CC     getlimits.o
  CC     libstdbuf_so-libstdbuf.o
  CC     su.o
  AR     libver.a
  CCLD   chroot
  CCLD   uname
  CCLD   hostid
  CCLD   nice
  CCLD   who
  CCLD   users
  CCLD   pinky
  CCLD   uptime
  CCLD   stty
  ...

Run "make V=1" if you want the verbose output you're used to.  Note that
I prefer the behavior shown above.  Remove the ([yes]) if you (as package
maintainer) want to provide the option, but with V=1 as default.

That may look trivial, but the reduced clutter makes surprising output
stand out more than it used to.  This has helped me find at least two
minor problems in coreutils and gnulib already.

parallel-tests is well worth it any time I run "make check"
on a multi-core system.  On a quad-core system, with many, fine-grained
tests, it cuts test run time by 70% or more.  Of course, it helps to
start the longest-running tests early enough so that they have a better
chance to complete before other cores go idle.

>From automake's NEWS: this was an important improvement for
projects that install many files into the same directory,
especially on systems with SELinux enabled (in some extreme
cases, this change resulted in a 30-X(!) speed-up):

  - The targets `install' and `uninstall' are more efficient now, in that
    for example multiple files from one Automake variable such as
    `bin_SCRIPTS' are copied in one `install' (or `libtool --mode=install')
    invocation if they do not have to be renamed.

color-tests is no big deal.
It gives you e.g., green "PASS" and red "FAIL" highlighting
in the output of "make check".

I like dist-xz because the compressed tarballs are so much
smaller than bzip2-compressed ones.  xz is the successor
to LZMA (http://tukaani.org/xz/).  I install it from source.

FYI, I do not make changes like these lightly.  I follow automake
development very closely and even contribute once in a while.
The standard of quality there is very high.  When I discovered that
some tools could compress tarballs 10-35% better than bzip2, I poked
and prodded the contenders.  Lzma-utils stood out for its quality of
implementation and it adherence to the de-facto gzip/bzip2 standards.
Due to a significant format change, the name has changed too, and now
the tool is called xz.

There are many more improvements and bug fixes in 1.11
that were not in any previous version.  See the NEWS file for
the complete list:

    http://git.sv.gnu.org/cgit/automake.git/plain/NEWS

> A rebase of an important package in three stable releases, which is
> expected to break rebuilds of some packages, should surely have more
> justification than an empty update description, no associated bugzilla
> and claims that Jim Meyering needs some unspecified new features.

I've been lamenting the 3-year-old version of automake in Fedora for
years, and worse, having to jump through hoops for projects like qpid,
parted, corosync, openais, etc. because I refuse to waste time working
around bugs/misfeatures that were fixed in upstream automake years before.
I've been helping people build from source and install their own
versions of these tools for use on Fedora-based systems.  This script
was essential before the upgrade to automake-1.11:

    http://et.redhat.com/~meyering/autotools-install

Distributing such an old version of automake (with no newer alternative)
was doing a disservice to Fedora developers everywhere.  That old version
of automake would inject its older, inferior infrastructure into every
Makefile.in and aclocal.m4, and from there into every package's configure
script.  People using stock Fedora were thus stuck with some 3-year-old bugs,
and could not take advantage of the numerous improvements made during
that period.  Fedora is better than that.

Thanks again to the Fedora automake maintainers.

Jim