Automake AM_COND_IF problem: libopts/Makefile.in split personality

[Dave Hart]

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