-New in 1.13.2:
+* 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". 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
+ 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, 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!
- - Automake 1.14 will require Autoconf 2.70 or later (which is still
+ - 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 1.14 is).
+ before Automake 2.0 is).
- - Automake 1.14 will drop support for the long-deprecated 'configure.in'
+ - Automake 2.0 will drop support for the long-deprecated 'configure.in'
name for the Autoconf input file. You are advised to start using the
recommended name 'configure.ac' instead, ASAP.
- The ACLOCAL_AMFLAGS special make variable will be fully deprecated
- in Automake 1.14 (where it will raise warnings in the "obsolete"
+ in Automake 2.0 (where it will raise warnings in the "obsolete"
category). You are advised to start relying on the new Automake
support for AC_CONFIG_MACRO_DIRS instead (which was introduced in
Automake 1.13).
- - Automake 1.14 will remove support for automatic dependency tracking
+ - Automake 2.0 will remove support for automatic dependency tracking
with the SGI C/C++ compilers on IRIX. The SGI depmode has been
reported broken "in the wild" already, and we don't think investing
time in debugging and fixing is worthwhile, especially considering
DJGPP project). Note however that both Cygwin and MSYS/MinGW on
modern Windows versions will continue to be fully supported.
- - Support for the long-deprecated INCLUDES variable will be removed
- altogether in Automake 1.14. The AM_CPPFLAGS variable should be
- used instead.
-
- Automake-provided scripts and makefile recipes might (finally!)
- start assuming a POSIX shell in Automake 1.14.
+ start assuming a POSIX shell in Automake 2.0.
- - Starting from Automake 1.14, third-party m4 files located in the
+ - Starting from Automake 2.0, third-party m4 files located in the
system-wide aclocal directory, as well as in any directory listed
in the ACLOCAL_PATH environment variable, will 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 '/usr/local/share/aclocal/my-vala.m4'
should take precedence over the same-named automake-provided macro
- (defined in '/usr/local/share/aclocal-1.14/vala.m4').
+ (defined in '/usr/local/share/aclocal-2.0/vala.m4').
-* Obsolescent features:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- - Use of suffix-less info files (that can be specified through the
- '@setfilename' macro in Texinfo input files) is discouraged, and
- its use will raise warnings in the 'obsolete' category.
+New in 1.14:
+
+* C compilation, and the AC_PROG_CC and AM_PROG_CC_C_O macros:
+
+ - The 'compile' script is now unconditionally required for all
+ packages that perform C compilation (note that if you are using
+ the '--add-missing' option, automake will fetch that script for
+ you, so you shouldn't need any explicit adjustment).
+ This new behaviour is needed to avoid obscure errors when the
+ 'subdir-objects' option is used, and the compiler is an inferior
+ one that doesn't grasp the combined use of both the "-c -o"
+ options; see discussion about automake bug#13378 for more details:
+ <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
+ <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>
+
+ - The next major Automake version (2.0) will unconditionally turn on
+ the 'subdir-objects' option. In order to smooth out the transition,
+ we now give a warning (in the category 'unsupported') whenever a
+ source file is present in a subdirectory but the 'subdir-object' is
+ not enabled. For example, the following usage will trigger such a
+ warning (of course, assuming the 'subdir-objects' option is off):
+
+ bin_PROGRAMS = sub/foo
+ sub_foo_SOURCES = sub/main.c sub/bar.c
+
+ - Automake will automatically enhance the AC_PROG_CC autoconf macro
+ to make it check, at configure time, that the C compiler supports
+ the combined use of both the "-c -o" options. This "rewrite" of
+ AC_PROG_CC is only meant to be temporary, since future Autoconf
+ versions should provide all the features Automake needs.
+
+ - The AM_PROG_CC_C_O is no longer useful, and its use is a no-op
+ now. Future Automake versions might start warning that this
+ macro is obsolete. For better backward-compatibility, this macro
+ still sets a proper 'ac_cv_prog_cc_*_c_o' cache variable, and
+ define the 'NO_MINUS_C_MINUS_O' C preprocessor symbol, but you
+ should really stop relying on that.
+
+* Texinfo support:
+
+ - Automake can now be instructed to place '.info' files generated from
+ Texinfo input in the builddir rather than in the srcdir; this is done
+ specifying the new automake option 'info-in-builddir'. This feature
+ was requested by the developers of GCC, GDB, GNU binutils and the GNU
+ bfd library. See the extensive discussion about automake bug#11034
+ for more details.
- - Use of Texinfo input files with '.txi' or '.texinfo' extensions
- is discouraged, and its use will raise warnings in the 'obsolete'
- category. You are advised to simply use the '.texi' extension
- instead.
+ - For quite a long time, Automake has been implementing an undocumented
+ hack which ensured that '.info' files which appeared to be cleaned
+ (by e.g. being listed in the CLEANFILES or DISTCLEANFILES variables)
+ were built in the builddir rather than in the srcdir; this hack was
+ introduced to ensure better backward-compatibility with packages such
+ as Texinfo, which did things like:
+
+ info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
+ DISTCLEANFILES = texinfo texinfo-* info*.info*
+ # Do not create info files for distribution.
+ dist-info:
+ @:
+
+ in order not to distribute generated '.info' files.
+
+ Now that we have the 'info-in-builddir' option that explicitly causes
+ generated '.info' files to be placed in the builddir, this hack should
+ be longer necessary, so we deprecate it with runtime warnings. It will
+ likely be removed altogether in Automake 2.0.
+
+* Relative directory in Makefile fragments:
+
+ - The special Automake-time substitutions '%reldir%' and '%canon_reldir%'
+ (and their short versions, '%D%' and '%C%' respectively) can now be used
+ in an included Makefile fragment. The former is substituted with the
+ relative directory of the included fragment (compared to the top level
+ including Makefile), and the latter with the canonicalized version of
+ the same relative directory:
+
+ bin_PROGRAMS += %reldir%/foo
+ %canon_reldir%_foo_SOURCES = %reldir%/bar.c
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.2:
* Documentation fixes:
- Other minor miscellaneous fixes and improvements; in particular,
some improvements in cross-references.
+* Obsolescent features:
+
+ - Use of suffix-less info files (that can be specified through the
+ '@setfilename' macro in Texinfo input files) is discouraged, and
+ its use will raise warnings in the 'obsolete' category. Simply
+ use the '.info' extension for all your info files, transforming
+ usages like:
+
+ @setfilename myprogram
+
+ into:
+
+ @setfilename myprogram.info
+
+ - Use of Texinfo input files with '.txi' or '.texinfo' extensions
+ is discouraged, and its use will raise warnings in the 'obsolete'
+ category. You are advised to simply use the '.texi' extension
+ instead.
+
* 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 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 merely report a
- warning in the 'unsupported' category. This is done to support
- some pre-existing real-world usages; refer to automake bug#13514
- for more details.
+ - 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).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~