Hi there
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
===
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?
regards
felix
PS: please CC replies to me, as i am not subscribed (yet).
[1] http://www.gnu.org/software/automake/manual/html_node/Suffixes.html