On Thu, 12 Feb 2009, Ralf Wildenhues wrote: > > 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.
Actually I've done a little more research here and it turns out that my initial understanding was flawed, which brings me to one of your later points. > In the other case, with ordinary makefile stuff only, I would include > them in a way that is not visible to automake. [...] > 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. Right you are, the user is instead expected to place @INC_AMINCLUDE@ in the Makefile.am. As you suggested this hides the inclusion from Automake. AX_ADD_AM_MACRO does not create Automake rules as the name would suggest but rather it creates _Make_ rules. Of course relying on includes like this in turn makes the build system less portible (as you mentioned). Ideally the macro archive would provide a way to produce these rules in a way that they would be available for Automake to work its magic. I'm working on a patch series that would allow macro developers provide an Automake include-able file which will be available before Automake is run. I'd be happy to CC this list if there is no objection. <offtopic> > Automake internally has a couple of substed variables for this, too. > The respective statement looks like this: > @am__include@ @am__qu...@file@am__quote@ Yes that's how Automake manages to provide dependencies as a side effect of compilation, right? I remember abusing this at one point to get the Autotools to make use of some automatic dependencies generated by a script of mine. :) </offtopic> Allan
