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 <stefano.lattarini@gmail.com>

diff --cc NEWS
index 46d6b2e,a6f0953..1cc00a4
--- 1/NEWS
--- 2/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:
 +    <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.  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:
 +
 +        <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:

diff --cc THANKS
Simple merge

diff --cc bin/automake.in
index 40b3181,835d3bd..283d1bb
--- 1/bin/automake.in
--- 2/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'});
        }

diff --cc t/list-of-tests.mk
Simple merge