Re: AX_ADD_AM_MACRO creates circular dependencies

[Ralf Wildenhues]

Hello Allan,

* Allan Caffee wrote on Wed, Feb 04, 2009 at 12:38:01AM CET:
> First of all I wasn't really sure where to start this thread so if
> this isn't the appropriate place I apologize.

This is very well appropriate here.

> 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.

Hmm, ok.

> 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.

Yep.

>  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.

Agreed, too.

If the aminclude.am file is to contain any stuff that is treated
specially by automake, then I assume that is desired though.

So really the question is whether aminclude.am should contain ordinary
makefile rules, where it is further irrelevant whether automake knows
about them or not; or whether aminclude.am may contain anything which
needs interpreted by automake.

In the latter case, the user simply needs 'automake', it would need to
be run after configure is run.  I'd provide an empty aminclude.am in the
tarball, and let configure update it only in case its contents would
change.

In the other case, with ordinary makefile stuff only, I would include
them in a way that is not visible to automake.  Here's how to achieve
this, for example:

Use some AC_SUBST'ed variable, which expands to either the contents of
the rule(s), or an include statement that includes your file.  Now,
the "normal" 'include' statement is interpreted by automake, at automake
run time, while the 'make' 'include' statement is interpreted by make,
at make run time.  It is also in practice not completely portable, even
though POSIX 2008 has now standardized one form of it (some make
implementations use '.include', or put quotes around the file name).

In fact, reading the documentation at
<http://autoconf-archive.cryp.to/ax_am_macros.html>,
it recommends a method that uses such a substituted variable.

Automake internally has a couple of substed variables for this, too.
The respective statement looks like this:
  @am__include@ @address@hidden@am__quote@

with FILE being the file to be included.  Note that this relies on
unpublished internal details, but in turn is portable to all kinds
of make implementations.

Hope that helps.

Cheers,
Ralf