GNU bug report logs - #14560
C Compilation variables present in output Makefiles unconditionally

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14560 in the body.
You can then email your comments to 14560 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Corsepius <ralf.corsepius <at> rtems.org>
Cc: bug-automake <at> gnu.org, Automake List <automake <at> gnu.org>
Subject: C Compilation variables present in output Makefiles unconditionally
Date: Wed, 05 Jun 2013 12:03:15 +0200

[+cc bug-automake, so this will be registered in the bug tracker]

On 06/05/2013 07:16 AM, Ralf Corsepius wrote:
> On 06/03/2013 09:14 PM, Stefano Lattarini wrote:
>> We are pleased to announce the GNU Automake 1.13.3 maintenance release.
> 
> When comparing automake-1.13.2 generated Makefile.ins against
> automake-1.13.3 generated Makefile.in, in projects which are
> _not_ using "c" I am observing changes like this one below:
> 
> --- a/Makefile.in
> +++ b/Makefile.in
> ...
> @@ -109,6 +109,18 @@ AM_V_at = $(am__v_at_ <at> AM_V@)
>  am__v_at_ = $(am__v_at_ <at> AM_DEFAULT_V@)
>  am__v_at_0 = @
>  am__v_at_1 =
> +COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
> +       $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
> +AM_V_CC = $(am__v_CC_ <at> AM_V@)
> +am__v_CC_ = $(am__v_CC_ <at> AM_DEFAULT_V@)
> +am__v_CC_0 = @echo "  CC      " $@;
> +am__v_CC_1 =
> +CCLD = $(CC)
> +LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
> +AM_V_CCLD = $(am__v_CCLD_ <at> AM_V@)
> +am__v_CCLD_ = $(am__v_CCLD_ <at> AM_DEFAULT_V@)
> +am__v_CCLD_0 = @echo "  CCLD    " $@;
> +am__v_CCLD_1 =
>  SOURCES =
>  DIST_SOURCES =
>  AM_V_DVIPS = $(am__v_DVIPS_ <at> AM_V@)
> ...
>
Yeah, this shouldn't happen.  Not a serious regression thankfully,
but still unpleasant.

> So far, I havn't had sufficient time to implement a simple reproducer,
> but I am inclined to believe, automake-1.13.3 inserts c-compiler
> related vars into Makefile.ins, in cases no C-compiler is being used.
>
Thanks for the report, I'll try to look into this ASAP (might be
few days though).  I already have in mind which set of changes
can be responsible for the regression (that is, those related to
the fixing of automake bug#14441).

Regards,
  Stefano

Message #12 received at 14560 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Corsepius <ralf.corsepius <at> rtems.org>
Cc: 14560 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: Re: bug#14560: C Compilation variables present in output Makefiles
	unconditionally
Date: Fri, 07 Jun 2013 19:41:50 +0200

submitter 14560 Ralf Corsepius <ralf.corsepius <at> rtems.org>
severity 14560 minor
tags 14560 + moreinfo
thanks

On 06/05/2013 12:03 PM, Stefano Lattarini wrote:
> [+cc bug-automake, so this will be registered in the bug tracker]
> 
> On 06/05/2013 07:16 AM, Ralf Corsepius wrote:
>> On 06/03/2013 09:14 PM, Stefano Lattarini wrote:
>>> We are pleased to announce the GNU Automake 1.13.3 maintenance release.
>>
>> When comparing automake-1.13.2 generated Makefile.ins against
>> automake-1.13.3 generated Makefile.in, in projects which are
>> _not_ using "c" I am observing changes like this one below:
>>
>> --- a/Makefile.in
>> +++ b/Makefile.in
>> ...
>> @@ -109,6 +109,18 @@ AM_V_at = $(am__v_at_ <at> AM_V@)
>>  am__v_at_ = $(am__v_at_ <at> AM_DEFAULT_V@)
>>  am__v_at_0 = @
>>  am__v_at_1 =
>> +COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
>> +       $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
>> +AM_V_CC = $(am__v_CC_ <at> AM_V@)
>> +am__v_CC_ = $(am__v_CC_ <at> AM_DEFAULT_V@)
>> +am__v_CC_0 = @echo "  CC      " $@;
>> +am__v_CC_1 =
>> +CCLD = $(CC)
>> +LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
>> +AM_V_CCLD = $(am__v_CCLD_ <at> AM_V@)
>> +am__v_CCLD_ = $(am__v_CCLD_ <at> AM_DEFAULT_V@)
>> +am__v_CCLD_0 = @echo "  CCLD    " $@;
>> +am__v_CCLD_1 =
>>  SOURCES =
>>  DIST_SOURCES =
>>  AM_V_DVIPS = $(am__v_DVIPS_ <at> AM_V@)
>> ...
>>
> Yeah, this shouldn't happen.  Not a serious regression thankfully,
> but still unpleasant.
> 
>> So far, I havn't had sufficient time to implement a simple reproducer,
>>
Any progress with this?  I haven't been able to reproduce the bug so
far.  Even if you cannot find a minimal reproducer, a tarball of the
package where you are encountering the issue might help.

>> but I am inclined to believe, automake-1.13.3 inserts c-compiler
>> related vars into Makefile.ins, in cases no C-compiler is being used.
>
> Thanks for the report, I'll try to look into this ASAP (might be
> few days though).  I already have in mind which set of changes
> can be responsible for the regression (that is, those related to
> the fixing of automake bug#14441).
> 

Thanks,
  Stefano

Message #17 received at 14560 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Corsepius <ralf.corsepius <at> rtems.org>
To: 14560 <at> debbugs.gnu.org
Cc: automake <at> gnu.org
Subject: Re: bug#14560: C Compilation variables present in output Makefiles
 unconditionally
Date: Tue, 11 Jun 2013 13:29:12 +0200

[Message part 1 (text/plain, inline)]

On 06/05/2013 12:03 PM, Stefano Lattarini wrote:
> [+cc bug-automake, so this will be registered in the bug tracker]
>
> On 06/05/2013 07:16 AM, Ralf Corsepius wrote:
>> On 06/03/2013 09:14 PM, Stefano Lattarini wrote:
>>> We are pleased to announce the GNU Automake 1.13.3 maintenance release.
>>
>> When comparing automake-1.13.2 generated Makefile.ins against
>> automake-1.13.3 generated Makefile.in, in projects which are
>> _not_ using "c" I am observing changes like this one below:
>>
>> --- a/Makefile.in
>> +++ b/Makefile.in
>> ...
>> @@ -109,6 +109,18 @@ AM_V_at = $(am__v_at_ <at> AM_V@)
>>   am__v_at_ = $(am__v_at_ <at> AM_DEFAULT_V@)
>>   am__v_at_0 = @
>>   am__v_at_1 =
>> +COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
>> +       $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
>> +AM_V_CC = $(am__v_CC_ <at> AM_V@)
>> +am__v_CC_ = $(am__v_CC_ <at> AM_DEFAULT_V@)
>> +am__v_CC_0 = @echo "  CC      " $@;
>> +am__v_CC_1 =
>> +CCLD = $(CC)
>> +LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
>> +AM_V_CCLD = $(am__v_CCLD_ <at> AM_V@)
>> +am__v_CCLD_ = $(am__v_CCLD_ <at> AM_DEFAULT_V@)
>> +am__v_CCLD_0 = @echo "  CCLD    " $@;
>> +am__v_CCLD_1 =
>>   SOURCES =
>>   DIST_SOURCES =
>>   AM_V_DVIPS = $(am__v_DVIPS_ <at> AM_V@)
>> ...
>>
> Yeah, this shouldn't happen.  Not a serious regression thankfully,
> but still unpleasant.
>
>> So far, I havn't had sufficient time to implement a simple reproducer,
>> but I am inclined to believe, automake-1.13.3 inserts c-compiler
>> related vars into Makefile.ins, in cases no C-compiler is being used.

Please find a reproducer enclosed below.

Untar the tarball and run autoreconf -fi.
Compare the files being generated by
automake-1.13.2+autoconf-2.69
against those being generated by
automake-1.13.3+autoconf-2.69

From what I can gather, something seems broken with automake-1.13.3's 
SUFFIX handling. Seems to me as is these extraneous variables are being 
generated when a Makefile use more than one suffix rule.

Ralf

[am-bug14560-20130611.tar.xz (application/x-xz, attachment)]

Message #20 received at 14560 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Corsepius <ralf.corsepius <at> rtems.org>
Cc: 14560 <at> debbugs.gnu.org,
 "automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#14560: C Compilation variables present in output Makefiles
 unconditionally
Date: Wed, 12 Jun 2013 12:25:11 +0200

tags 14560 - moreinfo
tags 14560 + patch
severity 14560 minor
stop

[+cc automake-patches, -cc automake]

On 06/11/2013 01:29 PM, Ralf Corsepius wrote:
> On 06/05/2013 12:03 PM, Stefano Lattarini wrote:
>> [+cc bug-automake, so this will be registered in the bug tracker]
>>
>> On 06/05/2013 07:16 AM, Ralf Corsepius wrote:
>>> On 06/03/2013 09:14 PM, Stefano Lattarini wrote:
>>>> We are pleased to announce the GNU Automake 1.13.3 maintenance release.
>>>
>>> When comparing automake-1.13.2 generated Makefile.ins against
>>> automake-1.13.3 generated Makefile.in, in projects which are
>>> _not_ using "c" I am observing changes like this one below:
>>>
>>> --- a/Makefile.in
>>> +++ b/Makefile.in
>>> ...
>>> @@ -109,6 +109,18 @@ AM_V_at = $(am__v_at_ <at> AM_V@)
>>>   am__v_at_ = $(am__v_at_ <at> AM_DEFAULT_V@)
>>>   am__v_at_0 = @
>>>   am__v_at_1 =
>>> +COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
>>> +       $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
>>> +AM_V_CC = $(am__v_CC_ <at> AM_V@)
>>> +am__v_CC_ = $(am__v_CC_ <at> AM_DEFAULT_V@)
>>> +am__v_CC_0 = @echo "  CC      " $@;
>>> +am__v_CC_1 =
>>> +CCLD = $(CC)
>>> +LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
>>> +AM_V_CCLD = $(am__v_CCLD_ <at> AM_V@)
>>> +am__v_CCLD_ = $(am__v_CCLD_ <at> AM_DEFAULT_V@)
>>> +am__v_CCLD_0 = @echo "  CCLD    " $@;
>>> +am__v_CCLD_1 =
>>>   SOURCES =
>>>   DIST_SOURCES =
>>>   AM_V_DVIPS = $(am__v_DVIPS_ <at> AM_V@)
>>> ...
>>>
>> Yeah, this shouldn't happen.  Not a serious regression thankfully,
>> but still unpleasant.
>>
>>> So far, I havn't had sufficient time to implement a simple reproducer,
>>> but I am inclined to believe, automake-1.13.3 inserts c-compiler
>>> related vars into Makefile.ins, in cases no C-compiler is being used.
> 
> Please find a reproducer enclosed below.
> 
> Untar the tarball and run autoreconf -fi.
> Compare the files being generated by
> automake-1.13.2+autoconf-2.69
> against those being generated by
> automake-1.13.3+autoconf-2.69
> 
> From what I can gather, something seems broken with automake-1.13.3's
> SUFFIX handling. Seems to me as is these extraneous variables are
> being generated when a Makefile use more than one suffix rule.
>
Thanks, this is exactly what I needed, and your diagnosis seems spot-on.
I will soon post a couple of patches that should first expose and then
fix the issue.  BTW, I notice your e-mail in THANKS might be outdated.
Should I replace it with the one you are using recently?

Regards,
  Stefano

Message #27 received at 14560 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake-patches <at> gnu.org
Cc: 14560 <at> debbugs.gnu.org, Ralf Corsepius <ralf.corsepius <at> rtems.org>
Subject: [PATCH 0/2] Fix automake bug#14560
Date: Wed, 12 Jun 2013 12:26:15 +0200

Will push this to 'micro' by tomorrow if there is no objection.
On-field testing would be appreciated.

Stefano Lattarini (2):
  tests: expose automake bug#14560
  lang, suffix rules: don't require C stuff needlessly

 NEWS                              | 11 ++++++
 automake.in                       |  9 ++---
 lib/Automake/Rule.pm              | 15 +-------
 t/list-of-tests.mk                |  2 ++
 t/no-extra-c-stuff.sh             | 74 +++++++++++++++++++++++++++++++++++++++
 t/no-extra-makefile-code.sh       |  9 +++--
 t/suffix-extra-c-stuff-pr14560.sh | 37 ++++++++++++++++++++
 7 files changed, 137 insertions(+), 20 deletions(-)
 create mode 100644 t/no-extra-c-stuff.sh
 create mode 100644 t/suffix-extra-c-stuff-pr14560.sh

-- 
1.8.3.rc3.260.g1462b67

Message #30 received at 14560 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake-patches <at> gnu.org
Cc: 14560 <at> debbugs.gnu.org, Ralf Corsepius <ralf.corsepius <at> rtems.org>
Subject: [PATCH 1/2] tests: expose automake bug#14560
Date: Wed, 12 Jun 2013 12:26:16 +0200

Automake needlessly generates definition of make variables related
to C compilation when two or more user-defined suffix rules are
present in a single Makefile.am.

* t/suffix-extra-c-stuff-pr14560.sh: New test, exposing the bug.
This test is still xfailing.
* t/no-extra-c-stuff.sh: New test, check for a potential related
regression.  This regression is not actually present here (so this
test passes), but it still took place in our first attempt at
fixing bug#14560 -- so this test has proven to be actually useful.
* t/no-extra-makefile-code.sh: Improve comments, and tighten the
grepping checks a little.
* t/list-of-tests.mk (handwritten_TESTS): Add the new tests.
(XFAIL_TESTS): Add the new xfailing test.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 t/list-of-tests.mk                |  3 ++
 t/no-extra-c-stuff.sh             | 74 +++++++++++++++++++++++++++++++++++++++
 t/no-extra-makefile-code.sh       |  9 +++--
 t/suffix-extra-c-stuff-pr14560.sh | 37 ++++++++++++++++++++
 4 files changed, 121 insertions(+), 2 deletions(-)
 create mode 100644 t/no-extra-c-stuff.sh
 create mode 100644 t/suffix-extra-c-stuff-pr14560.sh

diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 1d7cf87..f2eb648 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -42,6 +42,7 @@ t/remake-timing-bug-pr8365.sh \
 t/lex-subobj-nodep.sh \
 t/subobj-indir-pr13928.sh \
 t/subobj-vpath-pr13928.sh \
+t/suffix-extra-c-stuff-pr14560.sh \
 t/remake-am-pr10111.sh \
 t/remake-m4-pr10111.sh \
 $(perl_fake_XFAIL_TESTS)
@@ -695,6 +696,7 @@ t/mkinst2.sh \
 t/mkinst3.sh \
 t/mmode.sh \
 t/mmodely.sh \
+t/no-extra-c-stuff.sh \
 t/no-extra-makefile-code.sh \
 t/no-spurious-install-recursive.sh \
 t/nobase.sh \
@@ -1069,6 +1071,7 @@ t/suffix-chain.tap \
 t/suffix-custom-pr14441.sh \
 t/suffix-custom-subobj.sh \
 t/suffix-custom-subobj-and-specflg.sh \
+t/suffix-extra-c-stuff-pr14560.sh \
 t/symlink.sh \
 t/symlink2.sh \
 t/syntax.sh \
diff --git a/t/no-extra-c-stuff.sh b/t/no-extra-c-stuff.sh
new file mode 100644
index 0000000..de0dd12
--- /dev/null
+++ b/t/no-extra-c-stuff.sh
@@ -0,0 +1,74 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Check that Automake doesn't generated rules or definitions related
+# to compilation of C sources for a project that doesn't use nor need
+# a C Compiler.  Inspired by the issues reported in automake bug#14560.
+
+am_create_testdir=empty
+. test-init.sh
+
+cat > configure.ac <<END
+AC_INIT([$me], [1.0])
+AC_CONFIG_AUX_DIR([.])
+AM_INIT_AUTOMAKE
+AC_CONFIG_FILES([
+    Makefile
+    sub/Makefile
+    sub2/Makefile
+])
+AC_PROG_CXX
+AC_PROG_F77
+AC_OUTPUT
+END
+
+cat > Makefile.am <<END
+SUBDIRS = sub sub2
+bin_PROGRAMS = bar
+bar_SOURCES = bar.cc
+END
+
+mkdir sub sub2
+
+cat > sub/Makefile.am <<END
+bin_PROGRAMS = foo
+foo_SOURCES = foo.f
+END
+
+cat > sub2/Makefile.am <<END
+bin_PROGRAMS = baz
+baz_SOURCES = baz.cxx
+END
+
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing
+
+test   -f install-sh
+test ! -e compile
+
+# Sanity checks.
+$FGREP '$(CXX)' Makefile.in
+$FGREP '$(CXX)' sub2/Makefile.in
+$FGREP '$(F77)' Makefile.in sub2/Makefile.in && exit 1
+$FGREP '$(F77)' sub/Makefile.in
+$FGREP '$(CXX)' sub/Makefile.in && exit 1
+
+$EGREP '(^COMPILE|$\(CC\)|AM_V_CC)' \
+  Makefile.in sub/Makefile.in sub2/Makefile.in && exit 1
+
+:
diff --git a/t/no-extra-makefile-code.sh b/t/no-extra-makefile-code.sh
index 086b6c6..64ef502 100644
--- a/t/no-extra-makefile-code.sh
+++ b/t/no-extra-makefile-code.sh
@@ -1,5 +1,5 @@
 #!/bin/sh
-# Copyright (C) 1996-2013 Free Software Foundation, Inc.
+# Copyright (C) 2011-2013 Free Software Foundation, Inc.
 #
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -25,12 +25,17 @@ echo AC_OUTPUT >> configure.ac
 
 : > Makefile.am
 
+# Automake shouldn't need nor require these.
 rm -f depcomp compile
 
 $ACLOCAL
+
+# Don't use '--add-missing' here, so that we can implicitly
+# check that the auxiliary scripts 'compile' and 'depcomp'
+# are not spuriously required by Automake.
 $AUTOMAKE
 
-$EGREP 'DEFAULT_INCLUDES|@am__isrc@|-compile|\$\(OBJEXT\)|tab\.[ch]' \
+$EGREP 'INCLUDES|@am__isrc@|-compile|\$\(OBJEXT\)|tab\.[ch]' \
   Makefile.in && exit 1
 
 :
diff --git a/t/suffix-extra-c-stuff-pr14560.sh b/t/suffix-extra-c-stuff-pr14560.sh
new file mode 100644
index 0000000..45fdd17
--- /dev/null
+++ b/t/suffix-extra-c-stuff-pr14560.sh
@@ -0,0 +1,37 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Automake bug#14560: if multiple user-specified suffix rules were
+# present, Automake could generate useless definitions and rules
+# related to C compilation.
+
+. test-init.sh
+
+cat > Makefile.am <<'END'
+.foo.bar:
+	foo2bar -o $@ $<
+.baz.qux:
+	baz2qux -o $@ $<
+bin_SCRIPTS = a.bar b.qux
+END
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+
+$EGREP '\$\(CC\)|COMPILE|AM_V_CC|-compile|INCLUDES' Makefile.in && exit 1
+
+:
-- 
1.8.3.rc3.260.g1462b67

Message #33 received at 14560 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake-patches <at> gnu.org
Cc: 14560 <at> debbugs.gnu.org, Ralf Corsepius <ralf.corsepius <at> rtems.org>
Subject: [PATCH 2/2] lang, suffix rules: don't require C stuff needlessly
Date: Wed, 12 Jun 2013 12:26:17 +0200

This change fixes automake bug#14560: 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.

* automake.in (handle_languages): Fix logic to decide whether or not to
include definitions of C compilation related variables in the generated
Makefile.in: instead of doing so when two or more user-defined suffix
rules are seen (which is a completely bogus criterion), do so when two
or more compiled languages are used.
* lib/Automake/Rule.pm (suffix_rules_count): Remove as no longer used.
(@EXPORT): Adjust.
* t/list-of-tests.mk (XFAIL_TESTS): No longer list the test script
'suffix-extra-c-stuff-pr14560.sh', which now passes.
* NEWS: Update.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 NEWS                 | 11 +++++++++++
 automake.in          |  9 +++++----
 lib/Automake/Rule.pm | 15 +--------------
 t/list-of-tests.mk   |  1 -
 4 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/NEWS b/NEWS
index d540aab..a6f0953 100644
--- a/NEWS
+++ b/NEWS
@@ -91,6 +91,17 @@
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+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 --git a/automake.in b/automake.in
index 63d5bdf..835d3bd 100644
--- a/automake.in
+++ b/automake.in
@@ -1572,10 +1572,11 @@ 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'})
 	  unless defined $done{$languages{'c'}};
diff --git a/lib/Automake/Rule.pm b/lib/Automake/Rule.pm
index 7fe6474..a28a78d 100644
--- a/lib/Automake/Rule.pm
+++ b/lib/Automake/Rule.pm
@@ -29,8 +29,7 @@ use Automake::DisjConditions;
 require Exporter;
 use vars '@ISA', '@EXPORT', '@EXPORT_OK';
 @ISA = qw/Automake::Item Exporter/;
-@EXPORT = qw (reset register_suffix_rule suffix_rules_count
-              next_in_suffix_chain
+@EXPORT = qw (reset register_suffix_rule next_in_suffix_chain
 	      suffixes rules $KNOWN_EXTENSIONS_PATTERN
 	      depend %dependencies %actions register_action
 	      accept_extensions
@@ -465,18 +464,6 @@ sub register_suffix_rule ($$$)
     }
 }
 
-=item C<$count = suffix_rules_count>
-
-Return the number of suffix rules added while processing the current
-F<Makefile> (excluding predefined suffix rules).
-
-=cut
-
-sub suffix_rules_count ()
-{
-  return (scalar keys %_suffix_rules) - (scalar keys %_suffix_rules_builtin);
-}
-
 =item C<@list = suffixes>
 
 Return the list of known suffixes.
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index f2eb648..007094f 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -42,7 +42,6 @@ t/remake-timing-bug-pr8365.sh \
 t/lex-subobj-nodep.sh \
 t/subobj-indir-pr13928.sh \
 t/subobj-vpath-pr13928.sh \
-t/suffix-extra-c-stuff-pr14560.sh \
 t/remake-am-pr10111.sh \
 t/remake-m4-pr10111.sh \
 $(perl_fake_XFAIL_TESTS)
-- 
1.8.3.rc3.260.g1462b67

Message #38 received at 14560-done <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Corsepius <ralf.corsepius <at> rtems.org>
Cc: "automake-patches <at> gnu.org" <automake-patches <at> gnu.org>,
 14560-done <at> debbugs.gnu.org
Subject: Re: bug#14560: C Compilation variables present in output Makefiles
 unconditionally
Date: Wed, 12 Jun 2013 19:44:28 +0200

On 06/12/2013 04:14 PM, Ralf Corsepius wrote:
> On 06/12/2013 12:25 PM, Stefano Lattarini wrote:
>>
>> Thanks, this is exactly what I needed, and your diagnosis seems spot-on.
>> I will soon post a couple of patches that should first expose and then
>> fix the issue.
> I gave your patches some "life-testing" - AFAICT so far, they seem to
> resolve the issue. Thanks.
>
OK, thanks for testing.  I will push the patches shortly.  And I'm
closing this bug report.

>> BTW, I notice your e-mail in THANKS might be outdated.
> Yes, this address is outdated for many years ;)
> 
>> Should I replace it with the one you are using recently?
> Yes. I think replacing it with
>  ralf.corsepius <at> gmail.com
> would be appropriate.
>
Will do with a follow-up patch.

Best regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.