- New in 1.13.2:
+New in 1.14:
+
+* Aclocal search path:
+
+ - Third-party m4 files located in the system-wide aclocal directory,
+ as well as in any directory listed in the ACLOCAL_PATH environment
+ variable, now take precedence over "built-in" Automake macros.
+ For example, assuming Automake is installed in the '/usr/local'
+ hierarchy, a definition of the AM_PROG_VALAC macro found in file
+ (say) '/usr/local/share/aclocal/my-vala.m4' should take precedence
+ over the same-named automake-provided macro, as defined in file
+ '/usr/local/share/aclocal-1.14/vala.m4'.
+
+* Obsolescent features flagged:
+
+ - Use of the special makefile variable 'ACLOCAL_AMFLAGS' is deprecated.
+ To specify locations of extra m4 files, the 'AC_CONFIG_MACRO_DIR' or
+ 'AC_CONFIG_MACRO_DIRS' (the latter introduced with autoconf 2.70)
+ should be used instead. And use of the '--install' aclocal option in
+ 'ACLOCAL_AMFLAGS' has proved to be a bad idea anyway -- see automake
+ bug#9037.
+
+* Obsolete features removed:
+
+ - Support for the long-deprecated name 'configure.in' for the Autoconf
+ input file has been removed altogether. Just use the modern name
+ 'configure.ac' instead.
+
+ - Support for the long-obsolete variable $(ACLOCAL_M4_SOURCES) has
+ been removed. It should be safe to simply remove any definition
+ of it you have in your Makefiles.
+
+ - Support for the long-obsolete $(INCLUDES) variable has been finally
+ removed, in favour of the modern equivalent $(AM_CPPFLAGS).
+
+* Removed support for obsolete platforms:
+
+ - Support for automatic dependency tracking with the SGI C/C++ compilers
+ on IRIX has been removed. The SGI depmode had been reported broken
+ "in the wild" already, and we don't think investing time in debugging
+ and fixing it would have been worthwhile, especially considering that
+ SGI has last updated those compilers in 2006, and is expected to retire
+ support for them in December 2013:
+ <http://www.sgi.com/services/support/irix_mips_support.html>
+
+ - Support for DJGPP on MS-DOS and/or Windows 95/98/ME has been removed.
+ Note that both Cygwin and MSYS/MinGW on modern Windows versions will
+ continue to be fully supported.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ * WARNING: New versioning scheme for Automake.
+
+ - Starting with this version onward, Automake will use an update and
+ more rational versioning scheme, one that will allow users to know
+ which kind of changes can be expected from a new version, based on
+ its version number.
+
+ + Micro versions (e.g., 1.13.3, 2.0.1, 3.2.8) will introduce only
+ 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).
+
+ + 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.
+
+ + Major versions (now expected to be released every 18 or 24 months,
+ and not more often) can introduce new big features (possibly with
+ rough edges and not-fully-stabilized APIs), removal of deprecated
+ features, backward-incompatible changes of behaviour, and possibly
+ major refactorings (that, while ideally transparent to the user,
+ could introduce new bugs). Incompatibilities should however not
+ be introduced gratuitously and abruptly; a proper deprecation path
+ should be duly implemented in the preceding minor releases.
+
+ - 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.
+
+ - See discussion about automake bug#13578 for more details and
+ background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
* WARNING: Future backward-incompatibilities!
if (@user_includes)
{
+ # Don't explore the same directory multiple times. This is here not
+ # only for speedup purposes. We need this when the user has e.g.
+ # specified 'ACLOCAL_AMFLAGS = -I m4' and has also set
+ # AC_CONFIG_MACRO_DIR[S]([m4]) in configure.ac. This makes the 'm4'
+ # directory to occur twice here and fail on the second call to
+ # scan_m4_dirs([m4]) when the 'm4' directory doesn't exist.
+ # TODO: Shouldn't there be rather a check in scan_m4_dirs for
+ # @user_includes[0]?
+ @user_includes = uniq @user_includes;
+
# Don't complain if the first user directory doesn't exist, in case
# we need to create it later (can happen if '--install' was given).
- scan_m4_dirs (FT_USER, !$install, $user_includes[0]);
- scan_m4_dirs (FT_USER, 1, @user_includes[1..$#user_includes]);
+ scan_m4_dirs (FT_USER,
+ $install ? SCAN_M4_DIRS_SILENT : SCAN_M4_DIRS_WARN,
+ $user_includes[0]);
+ scan_m4_dirs (FT_USER,
+ SCAN_M4_DIRS_ERROR,
+ @user_includes[1..$#user_includes]);
}
- scan_m4_dirs (FT_SYSTEM, 1, @system_includes);
- scan_m4_dirs (FT_AUTOMAKE, 1, @automake_includes);
- scan_m4_dirs (FT_AUTOMAKE, SCAN_M4_DIRS_ERROR, @automake_includes);
+ scan_m4_dirs (FT_SYSTEM, SCAN_M4_DIRS_ERROR, @system_includes);
++ scan_m4_dirs (FT_AUTOMAKE, SCAN_M4_DIRS_ERROR, @automake_includes);
# Construct a new function that does the searching. We use a
# function (instead of just evaluating $search in the loop) so that
projects / thirdparty / automake.git / commitdiff
