[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AX_ADD_AM_MACRO creates circular dependencies

From: Ralf Wildenhues
Subject: Re: AX_ADD_AM_MACRO creates circular dependencies
Date: Thu, 12 Feb 2009 20:33:22 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

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)/  Users are then intended to add a line
> like
> include $(top_srcdir)/
> to whichever needs the provided functionality.  The
> problem with this is that now depends on
> And is created by configure.  And in turn configure
> cannot be run (successfully) without  So in order to even
> get a useable build system the developer has to touch

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.


>  Why?  Because
> is generated at configure-time and included Automake
> files are inserted into the when Automake runs.  This
> means that (even if the actual contents of are identical
> to those in the tarball) running ./configure && make on a source will
> (detecting the change in a dependency of automatically
> rerun Automake.

Agreed, too.

If the 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 should contain ordinary
makefile rules, where it is further irrelevant whether automake knows
about them or not; or whether 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 in the
tarball, and let configure update it only in case its contents would

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]