(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.
+ no serious 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).
to retire support for them in December 2013:
<http://www.sgi.com/services/support/irix_mips_support.html>
- - Future versions of Automake might remove support for MS-DOS and
- Windows 95/98/ME (support for them was offered by relying on the
- DJGPP project). Note however that both Cygwin and MSYS/MinGW on
- modern Windows versions will continue to be fully supported.
+ - Automake 2.0 will remove support for MS-DOS and Windows 95/98/ME
+ (support for them was offered by relying on the DJGPP project).
+ Note however that both Cygwin and MSYS/MinGW on modern Windows
+ versions will continue to be fully supported.
- Automake-provided scripts and makefile recipes might (finally!)
start assuming a POSIX shell in Automake 2.0.
- 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 combined use of both the "-c -o" options. The result of this
+ check is saved in the cache variable 'am_cv_prog_cc_c_o', and said
+ result can be overridden by pre-defining that variable.
+
+ - The AM_PROG_CC_C_O can still be called, but that should no longer
+ be necessary. This macro is now just a thin wrapper around the
+ Automake-enhanced AC_PROG_CC. This means, among the other things,
+ that its behaviour is changed in three ways:
+
+ 1. It no longer invokes the Autoconf-provided AC_PROG_CC_C_O
+ macros behind the scenes.
- - 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.
+ 2. It caches the check result in the 'am_cv_prog_cc_c_o'variable,
+ and not in a 'ac_cv_prog_cc_*_c_o' variable whose exact name
+ in only dynamically computed at configure runtime (sic!) from
+ the content of the '$CC' variable.
+
+ 3. It no longer automatically AC_DEFINE the C preprocessor
+ symbol 'NO_MINUS_C_MINUS_O'.
* Texinfo support:
bin_PROGRAMS += %reldir%/foo
%canon_reldir%_foo_SOURCES = %reldir%/bar.c
+* Deprecated distribution formats:
+
+ - The 'shar' and 'compress' distribution formats are deprecated, and
+ scheduled for removal in Automake 2.0. Accordingly, the use of the
+ 'dist-shar' and 'dist-tarZ' will cause warnings at automake runtime
+ (in the 'obsolete' category), and the recipes for the Automake-generated
+ targets 'dist-shar' and 'dist-tarZ' will unconditionally display
+ (non-fatal) warnings at make runtime.
+
+* New configure runtime warnings about "rm -f" support:
+
+ - To simplify transition to Automake 2.0, the shell code expanded by
+ AM_INIT_AUTOMAKE now checks (at configure runtime) that the default
+ 'rm' program in PATH 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" act as a no-op, instead of raising usage
+ error). If this is not the case,
+ the configure script is aborted, to call the attention of the user
+ on the issue, and invite him to fix his PATH. The checked 'rm'
+ behavior is very widespread in the wild, and will be required by
+ future POSIX version:
+
+ <http://austingroupbugs.net/view.php?id=542>
+
+ The user can still force the configure process to complete even in the
+ presence of a broken 'rm' by defining the ACCEPT_INFERIOR_RM_PROGRAM
+ environment variable to "yes". And the generated Makefiles should
+ still work correctly even when such broken 'rm' is used. But note
+ that this will no longer be the case with Automake 2.0 though, so, if
+ you encounter the warning, please report it to us ASAP (and try to fix
+ your environment as well).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.4:
+
+* Bugs fixed:
+
+ - Fix a minor regression introduced in Automake 1.13.3: when two or more
+ user-defined suffix rules were present in a single Makefile.am,
+ automake would needlessly include definition of some make variables
+ related to C compilation in the generated Makefile.in (bug#14560).
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.3:
+* Documentation fixes:
+
+ - The documentation no longer mistakenly reports that the obsolete
+ 'AM_MKDIR_PROG_P' macro and '$(mkdir_p)' make variable are going
+ to be removed in Automake 2.0.
+
* 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.
+ - Byte-compilation of Emacs lisp files could fail spuriously on
+ Solaris, when /bin/ksh or /usr/xpg4/bin/sh were used as shell.
+
+ - If the same user-defined suffixes were transformed into different
+ Automake-known suffixes in different Makefile.am files in the same
+ project, automake could get confused and generate inconsistent
+ Makefiles (automake bug#14441).
+ For example, if 'Makefile.am' contained a ".ext.cc:" suffix rule,
+ and 'sub/Makefile.am' contained a ".ext.c:" suffix rule, automake
+ would have mistakenly placed into 'Makefile.in' rules to compile
+ "*.c" files into object files, and into 'sub/Makefile.in' rules to
+ compile "*.cc" files into object files --- rather than the other
+ way around. This is now fixed.
+
+* 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, they 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. Remove brittleness due to the use of "make -e" in test cases.
+
+ 2. Seamlessly allow 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).
+
+ - Several spurious failures have been fixed (they hit especially
+ MinGW/MSYS builds). See automake bugs #14493, #14494, #14495,
+ #14498, #14499, #14500, #14501, #14517 and #14528.
+
+ - Some other minor miscellaneous changes and fixlets.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- The long-deprecated but still supported two-arguments invocation form
of AM_INIT_AUTOMAKE is documented once again. This seems the sanest
- thing to do, given that support for such an usage might need to remain
- in place for a unspecified amount of time in order to cater for people
+ thing to do, given that support for such usage might need to remain
+ in place for an unspecified amount of time in order to cater to people
who want to define the version number for their package dynamically at
configure runtime (unfortunately, Autoconf does not yet support this
scenario, so we cannot delegate the work to it).
- The serial testsuite harness is no longer reported as "deprecated",
- but as "discouraged". We have no plan to remove it, not to make its
+ but as "discouraged". We have no plan to remove it, nor to make its
use cause runtime warnings.
- The parallel testsuite is no longer reported as "experimental"; it
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