X-Git-Url: http://review.tizen.org/git/?p=platform%2Fupstream%2Fautomake.git;a=blobdiff_plain;f=NEWS;fp=NEWS;h=1cc00a48c4849229a7753b4dafc87c10c70eb686;hp=a6f095336320699356304d7cf97917d55e216005;hb=6febcd41b3dcf99a89aaf21329c00fdadcd68771;hpb=ddc755a63c4318f70e6743f9f0debd0614311699 diff --git a/NEWS b/NEWS index a6f0953..1cc00a4 100644 --- a/NEWS +++ b/NEWS @@ -91,6 +91,128 @@ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +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: + + + + 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: @@ -154,17 +276,6 @@ New in 1.13.3: New in 1.13.2: -* 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. - - - 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. - * Documentation fixes: - The long-deprecated but still supported two-arguments invocation form @@ -189,6 +300,25 @@ New in 1.13.2: - 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