I've put together a stripped-down example of a problem currently beguiling Harlan Stenn and myself with Automake used in the NTP reference implementation:
http://support.ntp.org/people/hart/am-libopts-subpkg.tar.gz The layout is: am-libopts-subpkg/ configure.ac Makefile.am top.c subproj/ configure.ac Makefile.am sub.c libopts/ m4/ ... Both top.c and sub.c are libopts clients, sharing the single subproj/libopts bundled copy. The problem is that sometimes subproj/libopts/Makefile.in is generated correctly by the subproj machinery, and other times it is generated incorrectly as if it were produced by the top-level configure. The incorrect resulting subproj/libopts/Makefile breaks "make distcheck" using GNU Make, though curiously FreeBSD's make is able to complete distcheck successfully. The incorrect subproj/libopts/Makefile contains "subdir = subproj/libopts" while the working one has "subdir = libopts". The distcheck break happens when subproj/libopts/Makefile attempts to regenerate itself using a missing automake invocation that contains an extra "subproj/" that makes the filename non-existent. In trying to straighten this out, I modified our copy of libopts/m4/libopts.m4, originally from Autogen 5.11.2, to add an optional second argument to LIBOPTS_CHECK which can be used to conditionalize the AC_CONFIG_FILES(libopts-dir/Makefile) under AM_COND_IF. The top-level configure.ac uses this facility, so that the top-level config.status does not generate subproj/libopts/Makefile as it would otherwise. Instead, subproj/config.status generates (from its perspective) libopts/Makefile. The current snag I'm having is with autoreconf -i from the top level. After autoreconf completes, subproj/libopts/Makefile.in is consistently incorrect. This can be worked around with, for example: autoreconf -i -v --no-recursive ; cd subproj ; autoreconf -i -v ; cd .. # in the srcdir After which subproj/libopts/Makefile.in is consistently correct. The workaround is only temporary, as invariably something triggers automake self-rebuilding magic and the miscreant libopts/Makefile.in stops progress again. It appears autoreconf (or automake invoked from autoreconf) is not respecting the conditionalization of AC_CONFIG_FILES(libopts-dir/Makefile) using AM_COND_IF in LIBOPTS_CHECK, so that a recursive autoreconf gives the wrong top_builddir and subdir in subproj/libopts/Makefile.in, while autoreconf from the subproj dir does the right thing. Your thoughts and wisdom are solicited. Can we avoid going back to a separate top-level copy of libopts required by the subpackage? How might I convince in-the-field Autoconf and Automake to stop fighting amongst the packages over which owns subproj/libopts/Makefile? Can you help me in my quest to stop grepping Makefiles before kicking off a "make distcheck"? :) Thanks for your time, Dave Hart