From: Stefano Lattarini Date: Wed, 12 Jun 2013 19:22:58 +0000 (+0200) Subject: Merge branch 'micro' into maint X-Git-Tag: v1.14~18 X-Git-Url: http://review.tizen.org/git/?p=platform%2Fupstream%2Fautomake.git;a=commitdiff_plain;h=6febcd41b3dcf99a89aaf21329c00fdadcd68771 Merge branch 'micro' into maint * micro: THANKS: update e-mall address for Ralf Corsepius lang, suffix rules: don't require C stuff needlessly tests: expose automake bug#14560 Signed-off-by: Stefano Lattarini --- 6febcd41b3dcf99a89aaf21329c00fdadcd68771 diff --cc NEWS index 46d6b2e,a6f0953..1cc00a4 --- a/NEWS +++ b/NEWS @@@ -91,128 -91,17 +91,139 @@@ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +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: + + - 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: diff --cc bin/automake.in index 40b3181,835d3bd..283d1bb --- a/bin/automake.in +++ b/bin/automake.in @@@ -1481,12 -1572,13 +1481,13 @@@ sub handle_languages ( # If the project is entirely C++ or entirely Fortran 77 (i.e., 1 # suffix rule was learned), don't bother with the C stuff. But if # anything else creeps in, then use it. - $needs_c = 1 - if $need_link || suffix_rules_count > 1; - - if ($needs_c) + my @languages_seen = map { $languages{$extension_map{$_}}->name } + (keys %extension_seen); + @languages_seen = uniq (@languages_seen); + $needs_c = 1 if @languages_seen > 1; + if ($need_link || $needs_c) { - &define_compiler_variable ($languages{'c'}) + define_compiler_variable ($languages{'c'}) unless defined $done{$languages{'c'}}; define_linker_variable ($languages{'c'}); }