From: Stefano Lattarini Date: Tue, 28 May 2013 19:04:39 +0000 (+0200) Subject: Merge branch 'micro' into maint X-Git-Tag: v1.13b~7 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=7c53e4c3d5120abd49e6ffd735b640af5353dd41;p=platform%2Fupstream%2Fautomake.git Merge branch 'micro' into maint * micro: NEWS: report recent documentation fix about AM_PROG_MKDIR_P NEWS: Automake 2.0 will assume "rm -f" without args work NEWS: fix a couple of typos in older entries --- 7c53e4c3d5120abd49e6ffd735b640af5353dd41 diff --cc NEWS index 1196c36,9ce9fc4..3bbcb16 --- a/NEWS +++ b/NEWS @@@ -91,130 -91,14 +91,136 @@@ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +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: + + + + - 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. 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. + + 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: + + - 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. + + - 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 + +* 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: + + 7 + + 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.3: + * Documentation fixes: + + - The documentation no longer mistakenly report 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,