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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
