+ 2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ tests: fix failure due to debugging code forgotten into a test
+ * tests/missing-tar.test: Don't ever call the `missing' script
+ with `sh -x'; this was used for debugging, but an instance of
+ it slipped into the committed test case. Bug revealed by a
+ failure on a Solaris 10 system with GNU tar installed as `gtar'.
+
+2011-12-23 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ tests: avoid spurious failure of libtool and gettext tests
+
+ On Solaris 10 (and presumably earlier), /bin/sh trips up on
+ here-documents that contains a command substitution *and* are
+ fed to a shell function:
+
+ # All as expected.
+ $ cat <<END
+ `pwd`
+ END
+ /home/stefano
+ $ echo status = $?
+ status = 0
+
+ # An apparently innocuous function ...
+ $ kitty () { cat; }
+ # ... but hilarity ensues!
+ $ kitty <<END
+ `pwd`
+ END
+ /tmp/sh137723: cannot open
+ $ echo status = $?
+ status = 1
+
+ We need to work around this misbehaviour in a couple of our
+ tests (whose failures where causing cascading failures in a
+ lot of other tests).
+
+ * tests/gettext-macros.test: Avoid the use of command substitution
+ in a here-document passed to the `indent' function, by using the
+ `echo' builtin instead.
+ * tests/libtool-macros.test: Likewise.
+
+ See also:
+ <http://lists.gnu.org/archive/html/bug-autoconf/2011-12/msg00001.html>
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ hacking: distribute it, and mention it in the ChangeLog
+ Not distributing the HACKING file might make it more difficult,
+ for some random curious user, to get informed about or interested
+ in the Automake development process, or to send us patches.
+ * Makefile.am (EXTRA_DIST): Add HACKING.
+ * HACKING: It's OK to distribute this file, and to mention it in
+ the ChangeLog.
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ regex: deprecate the obsolete macro AM_WITH_REGEX
+ This is a backport of commit v1.11-433-g37b0aee.
+ Today, practically nobody uses the GNU rx library, which, according
+ to its own website <http://www.gnu.org/software/rx/rx.html>, has
+ been "decommissioned". Consequently, the automake-provided macro
+ AM_WITH_REGEX is not used nor required anymore. Deprecate it, so
+ that it will be possible to safely remove it in the next major
+ automake version.
+ * m4/regex.m4 (AM_WITH_REGEX): Give a warning of the class
+ `obsolete' when this macro is used.
+ * doc/automake.texi (Public Macros): Move description of
+ `AM_WITH_REGEX' from here ...
+ (Obsolete Macros): ... to here, and declare it as obsolete
+ and "to be removed in a future version".
+ * tests/regex-obsolete.test: New test.
+ * tests/Makefile.am (TESTS): Add it.
+ * NEWS: Update.
+ See also:
+ <http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00131.html>
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ maint: distribute .xz tarballs, not .bz2 ones
+ Many GNU packages are moving towards xz-compressed tarballs, so
+ let's follow suit, by dropping the creation and distribution of
+ a bzip2-compressed tarball and switching to xz instead.
+ For compatibility and safeness, we will continue to create and
+ distribute a gzip-compressed tarball as well.
+ * configure.ac (AM_INIT_AUTOMAKE): Drop `dist-bzip2', add
+ `dist-xz'.
+ * NEWS: Update
+ Suggested by Jim Meyering.
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ include: avoid "deleted .am file" problem
+ * automake.in (handle_configure): When processing `configure.am',
+ also expand `HAVE-MAKEFILE-IN-DEPS' to a boolean telling whether
+ `MAKEFILE-IN-DEPS' is empty or not.
+ * lib/am/configure.am [?HAVE-MAKEFILE-IN-DEPS?]
+ (%MAKEFILE-IN-DEPS%): New target without dependencies, to
+ avoid the "deleted .am file" problem. Emit this only when
+ `?HAVE-MAKEFILE-IN-DEPS?' is true, to avoid generating an
+ "empty" dependency declaration.
+ * tests/deleted-am.test: Make grepping of error message stricter.
+ * tests/dist-missing-am.test: Likewise.
+ * tests/remake-deleted-am.test: New test.
+ * tests/remake-deleted-am-2.test: Likewise.
+ * tests/remake-deleted-am-subdir.test: Likewise.
+ * tests/remake-renamed-am.test: Likewise.
+ * tests/makefile-deps.test: Likewise.
+ * tests/Makefile.am (TESTS): Add the new tests.
+ * NEWS: Update.
+ Fixes automake bug#9768.
+ Report by Peter Johansson.
+ See also commit `Release-1-10-40-gd0ebf71', which fixed a similar
+ problem for .m4 files included by configure.ac.
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ maint: better use of autoconf 2.68 features
+ * configure.ac: Now that Automake requires autoconf 2.68 for its
+ own bootstrapping and build system, we can assume that PACKAGE_URL
+ gets automatically AC_SUBT'd.
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ cosmetics: use proper m4 quoting in configure.ac
+ * configure.ac (AC_CONFIG_SRCDIR): Use proper m4 quoting
+ for its arguments.
+ (AC_CONFIG_AUX_DIR): Likewise.
+ (AC_PROG_PATH): Likewise.
+
+2011-12-14 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ tests: better handling of gettext and libtool requirements
+
+ This change fixes automake bug#9807.
+
+ Before this change, the automake testsuite only looked for the
+ `.m4' files containing libtool and gettext macros definitions in
+ the directory `${prefix}/share/aclocal' (and in the directories
+ specified by the `dirlist' file in there, if any), where ${prefix}
+ was the configure-time automake installation prefix (defaulting
+ to `/usr/local').
+
+ This approach had various shortcomings and disadvantages. Let's
+ briefly describe the three major ones.
+
+ First, on most GNU/Linux systems, a libtool or gettext installed
+ from distro-provided packages (e.g., by dpkg on Debian/Ubuntu, or
+ by rmp on RedHat/Fedora) would have `/usr', not `/usr/local', as
+ its ${prefix}; so, trying to run the automake testsuite with a
+ simple "./configure && make && make check" would have failed to
+ execute the libtool and gettext tests on most GNU/Linux distros.
+ It's true that it was quite easy to work around this issue, by
+ creating a proper `/usr/local/share/aclocal/dirlist' file with
+ an entry pointing to `/usr/share/aclocal' (a workaround in fact
+ used by most automake developers); but the typical user wasn't
+ aware of the necessity of this trick, so the libtool and gettext
+ tests was usually skipped on testsuite runs "in the wild", thus
+ needlessly reducing coverage.
+
+ Second, the older testsuite behaviour made more difficult for
+ the developers to run the testsuite with non-default libtool or
+ gettext. For example, assume the developer is working on a system
+ that has a default libtool version 1.5 installed in the /usr/local
+ hierarchy; to improve coverage, the developer installs also a more
+ modern libtool version, say 2.4, in its home directory, let's say
+ in ~/libtool-2.4; he then tries to run the automake testsuite with
+ this more modern libtool by doing an (apparently) simple:
+ $ PATH=$HOME/libtool-2.4:$PATH make check
+ But the automake testsuite would still look for libtool macros in
+ /usr/local/share/aclocal, not in ~/libtool-2.4/share/aclocal, so
+ the wrong version of the macros would be picked up, and the tests
+ would either fail spuriously or (which would be worse) pass without
+ truly covering the libtool version the developers was thinking to
+ be testing with.
+ Worse again, the automake testsuite would *unconditionally* look
+ for libtool macros in /usr/local/share/aclocal, so even something
+ like:
+ $ export ACLOCAL_PATH=$HOME/libtool-2.4/share/aclocal
+ $ PATH=$HOME/libtool-2.4:$PATH make check
+ wouldn't work.
+
+ Third and last, during a "make distcheck", automake is configured
+ with a ${prefix} pointing to a proper subdirectory of the build
+ directory (usually `pwd`/_inst), which gets created on-the-fly;
+ in this case, with the old approach, the automake testsuite never
+ found the libtool and gettext macro files, ans so the libtool and
+ gettext tests was *always* skipped in a "make distcheck".
+
+ * tests/libtool-macros.test: New helper test, looking (with the
+ help of the `libtoolize' script) for libtool macro files required
+ by most libtool tests, and making them easily accessible.
+ * tests/gettext-macros.test: New helper test, looking (with the
+ help of the `libtoolize' script) for libtool macro files required
+ by most libtool tests, and making them easily accessible.
+ * tests/defs.in: Update to make it rely on the results and setups
+ of `libtool-macros.test' and `gettext-macros.test'.
+ * tests/Makefile.am: Declare dependency of all the logs of libtool
+ tests from `libtool-macros.log', and all the logs of gettext tests
+ from `gettext-macros.log'.
+ (TESTS): Add the new tests.
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ fix: typos and grammaros in comments of the new test
+ * tests/get-sysconf.test: Fix few typos, grammaros and botched
+ wording. Reported by Eric Blake.
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ tests: report useful system information in 'test-suite.log'
+ It has already happened various times that a user has run the
+ automake testsuite, experienced a failure, read the messages
+ telling him "See tests/test-suite.log" and "Please report to
+ bug-automake@gnu.org", and done exactly that -- sending us only
+ the contents of `tests/test-suite.log', which are usually not
+ enough to start debugging the reported failure. So we have to
+ ask him for more details, and usually also for the `config.log'
+ file generated by configure. It's time to fix this recurring
+ feedback inefficiency. We do so by creating a dummy test case
+ that takes care of copying the contents of `config.log', plus
+ other useful system information, in the final `test-suite.log'.
+ * tests/get-sysconf.test: New test, gathering system information
+ and then always terminating with a SKIP, so that its output gets
+ copied in `test-suite.log'.
+ * tests/Makefile.am (TESTS): Add it.
+
+2011-12-07 Reuben Thomas <rrt@sc3d.org> (tiny change)
+
+ python: remove relics for Python 1.5 support
+ * m4/python.m4: The comments in here claim to support only
+ Python >= 2.0, yet this file still has specific support for
+ Python 1.5. Just remove it, python 1.5 is 12 years old now,
+ and practically defunct.
+ * NEWS: Update.
+ See also commit `Release-1-10-205-gd5bec12', "Support for
+ Python 3.0, drop support for pre-2.0."
+
+2011-12-21 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ configure: remove extraneous 'eval's from AM_RUN_LOG invocations
+ * configure.ac: Remove extra 'eval's from AM_RUN_LOG invocations;
+ for example, instead of "AM_RUN_LOG([eval $PERL --version])",
+ simply use "AM_RUN_LOG([$PERL --version])"
+
+2011-12-21 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ configure: report TeX version in config.log
+ * configure.ac: If possible, report the version of the selected
+ TeX program; this should render the logs more informative.
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ maint: snapshots from `maint' are still development snapshots
+ The maintenance-oriented development line in the `maint' branch,
+ while being usually pretty stable and 99% backward-compatible,
+ is not always right off production-quality; but until now, the
+ Automake package version declared in configure.ac hid this fact,
+ since it appeared to be the version of a stable release (e.g.,
+ 11.1). Fix this.
+ * configure.ac (AC_INIT): Bump version to "1.11.0a".
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ configure: print proper message for test releases
+ * configure.ac: If the current release is detected to be a test
+ release or a development snapshot, print a proper warning for
+ the user.
+ * README-alpha: Delete, it's obsolete now (and in fact this file
+ hasn't been touched in eleven years, since release 1.4b or so).
+ * HACKING (Release procedure): Don't say to update README-alpha.
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ devel: help in comparing Makefile.in from different commits
+ Now that the generated Makefile.in, configure and aclocal.m4 files
+ are no longer committed in Automake's git repository, a simple
+ "git diff" or "git log" no longer shows if and how a change in
+ Automake results in changes to the Makefile.in files and/or
+ configure script of its own build system. Still, the ability to
+ peek so easily at such differences has proved itself quite useful
+ in the past, often revealing inconsistencies and blunders, and
+ sometimes even bugs; so it would be a pity to lose that altogether.
+ With this change, we add a new maintainer recipe that re-introduces
+ much of that capability, by generating and comparing on the fly the
+ Makefile.in, configure and aclocal.m4 derived from two arbitrary
+ commits of the Automake repository.
+ * Makefile.am (autodiffs, compare-autodiffs): New phony targets.
+
+2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
+
+ repo: don't commit generated files in the git repository anymore
+ It has been quite some time since autoconf and libtool have stopped
+ committing the generated autotools files in their git repositories,
+ with no significant ill effects we're aware of. It's true that the
+ autoconf bootstrap process has now the minor annoyance that a
+ pre-installed autoconf is required to complete it; but luckily
+ automake will not have a similar annoyance, since our bootstrap
+ script take care, through some hoops, to use the very automake and
+ aclocal versions from the current git checkout to generate the
+ required aclocal.m4 and Makefile.in files. In fact, this has been
+ a necessity also in the past, because automake has been known to
+ use in its own build system new development features that hadn't
+ been present in any previously released automake distribution.
+ * .gitignore: Ignore configure, aclocal.m4, and all the
+ Makefile.in files.
+ * configure.ac (AC_PREREQ): New macro call, to require the
+ latest autoconf (2.68 for the moment).
+
2011-12-22 Stefano Lattarini <stefano.lattarini@gmail.com>
missing: don't try to re-run tar with a munged command line
projects / thirdparty / automake.git / commitdiff
