documentation updates and bug and regression fixes; they will
not introduce new features, nor any backward-incompatibility (any
such incompatibility would be considered a bug, to be fixed with
- a further micro release).
+ a further micro release).
+ Minor versions (e.g., 1.14, 2.1) can introduce new backward
compatible features; the only backward-incompatibilities allowed
in such a release are new *non-fatal* deprecations and warnings,
and possibly fixes for old or non-trivial bugs (or even inefficient
behaviours) that could unfortunately have been seen, and used, by
- some developers as "corner case features". This kind of fixes
- should hopefully be quite rare.
+ some developers as "corner case features". Possible disruptions
+ caused by this kind of fixes should hopefully be quite rare.
+ Major versions (now expected to be released every 18 or 24 months,
and not more often) can introduce new big features (possibly with
- According to this new scheme, the next major version of Automake
(the one that has until now been labelled as '1.14') will actually
become "Automake 2.0". Automake 1.14 will be the next minor version,
- which will introduce new features and deprecation, but no backward
- incompatibility.
+ which will introduce new features, deprecations and bug fixes, but
+ no real backward incompatibility.
- See discussion about automake bug#13578 for more details and
background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
* WARNING: Future backward-incompatibilities!
+ - Makefile recipes generated by Automake 2.0 will expect to use an
+ 'rm' program that doesn't complain when called without any non-option
+ argument if the '-f' option is given (so that commands like "rm -f"
+ and "rm -rf" will act as a no-op, instead of raising usage errors).
+ Accordingly, AM_INIT_AUTOMAKE will expand new shell code checking
+ that the default 'rm' program in PATH satisfies this requirement, and
+ aborting the configure process if this is not the case. This behavior
+ of 'rm' is very widespread in the wild, and it will be required in the
+ next POSIX version:
+ <http://austingroupbugs.net/view.php?id=542>
+
- Automake 2.0 will require Autoconf 2.70 or later (which is still
unreleased at the moment of writing, but is planned to be released
before Automake 2.0 is).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+New in 1.13.3:
+
+* Bugs fixed:
+
+ - Byte-compilation of Emacs lisp files could fail spuriously on Solaris,
+ when /bin/ksh or /usr/xpg4/bin/sh were used as shell.
+
+* Testsuite work:
+
+ - The test cases no longer have the executable bit set. This should
+ make it clear that they are not meant to be run directly; as
+ explained in t/README, the can only be run through the custom
+ 'runtest' script, or by a "make check" invocation.
+
+ - The testsuite has seen the introduction of a new helper function
+ 'run_make', and several related changes. These serve a two-fold
+ purpose:
+
+ 1. Removing brittleness due to the use of "make -e" in test cases.
+
+ 2. Seamlessly allowing the use of parallel make ("make -j...") in
+ the test cases, even where redirection of make output is involved
+ (see automake bug#11413 for a description of the subtle issues in
+ this area).
+
+ - Some other minor, miscellaneous changes and fixlets.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
New in 1.13.2:
* Obsolescent features:
* Bugs fixed:
+ - When the 'ustar' option is used, the generated configure script no
+ longer risks hanging during the tests for the availability of the
+ 'pax' utility, even if the user running configure has a UID or GID
+ that requires more than 21 bits to be represented.
+ See automake bug#8343 and bug#13588.
+
- The obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC work once
again, as they did in Automake 1.12.x (albeit printing runtime
warnings in the 'obsolete' category). Removing them has turned
Automake 1.13, has turned out to be a similarly very bad idea,
for exactly the same reason.
+ - aclocal will no longer error out if the first local m4 directory
+ (as specified by the '-I' option or the 'AC_CONFIG_MACRO_DIRS' or
+ 'AC_CONFIG_MACRO_DIR' macros) doesn't exist; it will merely report
+ a warning in the 'unsupported' category. This is done to support
+ some pre-existing real-world usages. See automake bug#13514.
+
+ - aclocal will no longer consider directories for extra m4 files more
+ than once, even if they are specified multiple times. This ensures
+ packages that specify both
+
+ AC_CONFIG_MACRO_DIR([m4]) in configure.ac
+ ACLOCAL_AMFLAGS = -I m4 in Makefile.am
+
+ will work correctly, even when the 'm4' directory contains no
+ package-specific files, but is used only to install third-party
+ m4 files (as can happen with e.g., "libtoolize --install").
+ See automake bug#13514.
+
+ - Analysis of make flags in Automake-generated rules has been made more
+ robust, and more future-proof. For example, in presence of make that
+ (like '-I') take an argument, the characters in said argument will no
+ longer be spuriously considered as a set of additional make options.
+ In particular, automake-generated rules will no longer spuriously
+ believe to be running in dry mode ("make -n") if run with an invocation
+ like "make -I noob"; nor will they believe to be running in keep-going
+ mode ("make -k") if run with an invocation like "make -I kool"
+ (automake bug#12554).
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.1:
tar-pax. The new option filename-length-max=99 helps diagnosing
filenames that are too long for tar-v7. (PR/414)
- - Variables aumented with `+=' are now automatically flattened (i.e.,
- trailing backslashes removed) and then wrapped around 80 colummns
+ - Variables augmented with `+=' are now automatically flattened (i.e.,
+ trailing backslashes removed) and then wrapped around 80 columns
(adding trailing backslashes). In previous versions, a long series
of
VAR += value1
projects / platform / upstream / automake.git / blobdiff