bug#14441: bug in new file extensions

[Stefano Lattarini]

severity 14441 minor
tags 14441 + patch
stop

Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14441>

On 05/22/2013 09:35 PM, Felix Salfelder wrote:
> Hi there
>
Hi Felix, sorry for the delay.

> i have discovered a bug in file extensions handling [1]. consider two
> Makefile.am's (skipping hopefully unneeded information):
> 
> === $(top_srcdir)/Makefile.am:
> SUBDIRS = bug
> lib_LTLIBRARIES = libone.la
> libone_la_SOURCES = one.ext
> 
> .ext.cc:
>       #whatever
> ===
> 
> === $(top_srcdir)/bug/Makefile.am:
> lib_LTLIBRARIES = libtwo.la
> libtwo_la_SOURCES = two.ext
> 
> .ext.c:
>       #whatever else
> ===
>
Yikes, having files with the same extension turned into C sources in one
Makefile and C++ files in another seems very confusing, and likely the
recipe for a minor disaster.  Still, that's not a good reason for Automake
to mishandle the situation.  We should behave correctly, and allow the
user to shoot himself in the foot if he really wants to.

> here, the misuse of the extension .ext is intentional. libone is meant
> to be compiled from one.cc and libtwo from two.c. automake -v reports
> something different.
> 
> [..]
> automake: thread 0: reading Makefile.am
> automake: thread 0: Sources ending in .ext become .cc
> [..]
> automake: thread 0: creating Makefile.in
> automake: thread 0: reading bug/Makefile.am
> automake: thread 0: Sources ending in .ext become .c
> 
> and then (wrong):
> 
> automake: thread 0: Sources ending in .cc become .o
> automake: thread 0: Sources ending in .cc become .obj
> automake: thread 0: Sources ending in .cc become .lo
> automake: thread 0: creating bug/Makefile.in
> [..]
> 
> within bug/Makefile.in, automake writes (wrong)
> .cc.lo:
>       # LTCXXCOMPILE command
> instead of the needed .c.lo rule.
> 
> after "touch bug/Makefile.am; make -C bug Makefile" bug/Makefile.in
> correctly contains
> .c.lo:
>       # LTCOMPILE command
> instead.
> 
> i suspect there's something wrong with $extension_map scoping and
> initialize_per_input, but i have no clue how to fix it. would you agree
> that this is a bug?
>
Yes.  Confirmed and fixed.  I will soon post a patch series about the
fix (and other related refactories thrown in "while at it").

> regards
> felix
> 
> PS: please CC replies to me, as i am not subscribed (yet).
>
Keeping the OP in CC: is the default policy here; we can't expect anyone
who reports a bug to subscribe himself to our mailing list :-)

> [1] http://www.gnu.org/software/automake/manual/html_node/Suffixes.html
> 

Thanks,
  Stefano