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