AX_ADD_AM_MACRO creates circular dependencies

[Allan Caffee]

First of all I wasn't really sure where to start this thread so if this isn't
the appropriate place I apologize.

I've noticed that a handful of the packages in the Autoconf archives use the
macros AX_ADD_AM_MACRO and AX_ADD_RECURSIVE_AM_MACRO.  These macros add targets
and variable assignments to a generated file $(top_srcdir)/aminclude.am.  Users
are then intended to add a line like

include $(top_srcdir)/aminclude.am

to whichever Makefile.am needs the provided functionality.  The problem with
this is that Makefile.in now depends on aminclude.am.  And aminclude.am is
created by configure.  And in turn configure cannot be run (successfully)
without Makefile.in.  So in order to even get a useable build system the
developer has to touch aminclude.am.

This circular dependency is inconvenient for developers but what's
even worse is that any user who tries to compile this project from a
source tarball must now have Automake installed.  Why?  Because
aminclude.am is generated at configure-time and included Automake
files are inserted into the Makefile.in when Automake runs.  This
means that (even if the actual contents of aminclude.am are identical
to those in the tarball) running ./configure && make on a source will
(detecting the change in a dependency of Makfile.am) automatically
rerun Automake.

One possible solution to this would be to have the macros responsible
for generating Automake code instead create the file when Autoconf is
run via something like

m4_esyscmd([printf "$2" >> $1])

This should guarantee that the files exist and have the right content
before Automake begins to run.

I'm including a simple example that demonstrates this issue.  Thoughts?

        Allan

configure.ac
Description: Text document

hello.c
Description: Text Data

Makefile.am
Description: Text document