automake
[Top][All Lists]
Advanced

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

Re: Strangeness with m4_include and aclocal.


From: Stefano Lattarini
Subject: Re: Strangeness with m4_include and aclocal.
Date: Thu, 28 Oct 2010 19:58:54 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Wednesday 27 October 2010, Nick Bowler wrote:
> On 2010-10-23 15:23 +0200, Stefano Lattarini wrote:
> > Now I do.  This happens because `aclocal', to find the includes in an
> > input file, *grep* the file's content, looking for literal `m4_include'
> > (and similar), without analyzing m4 traces (not sure why aclocal acts
> > this way, but I suspect there is a good reason behind this behaviour).
> 
> So it seems that there is a strange dichotomy between automake and
> aclocal: automake apparently uses the traces to figure out the aclocal
> dependencies (also for 'make dist'), but aclocal _doesn't_ use the
> traces to actually do things.
Well, if you consider what aclocal has to accomplish, it's pretty clear
it has (partly at least) to work by grepping rather than tracing.  The
real problem here, as you pointed out, is the dichotomy between automake
and aclocal w.r.t. the calculation of aclocal.m4 dependencies.
 
> > So I think your first problem is "just" an aclocal limitation we should
> > resign to live with.  But I also think that such a limitation should be
> > documented explicitly, since it's by no means obvious.
> 
> It's especially non-obvious because the other autotools handle this just
> fine.
Agreed.
 
> > > so it believes that aclocal.m4 is out of date when foo.m4 is updated.
> >
> > And this is right, because configure.ac includes foo.m4, and since
> > aclocal.m4 depends on all the content of configure.ac, *also the parts
> > m4_included from other files*, aclocal.m4 must be considered out-of-date
> > when it's older than foo.m4.  What is wrong is that aclocal fails to
> > update the aclocal.m4 timestamp, so that the rules to rebuild it are
> > uselessly called over and over ...
> 
> Ah right.  Foo.m4 might call AC_DEFUN or another macro defined in
> this way, and aclocal needs to know about these things.
True (well, sort of).  For example, with the following setup:

  $ cat configure.ac
  AC_INIT([test], [1.0])
  FOO
  $ cat m4/bar.m4
  AC_DEFUN([MY_INC], [m4_][include([$1])])
  $ cat m4/baz.m4
  MY_INC([m4-extra/foo.m4])
  $ cat m4-extra/foo.m4
  AC_DEFUN([FOO], [BAR])

we'll have:

  $ aclocal -I m4 && autoconf
  $ sed -n '$p' configure
  FOO

which suggests that the inclusion of `m4-extra/foo.m4' wasn't seen
and processed by aclocal; but changhing the setup so that:

  $ cat m4/baz.m4
  m4_include([m4-extra/foo.m4])

we'll have:

  $ aclocal -I m4 && autoconf
  $ sed -n '$p' configure
  BAR

as expected.

> In my instance, foo.m4 _doesn't_ do either of these things so I didn't
> notice this.  If I'm understanding correctly, then, aclocal _isn't_
> going to find this information from foo.m4 because it doesn't _know_
> about foo.m4.
Yes, in the general case this is a possibility (see example above).

I'm starting to think that it would be aclocal's duty to inform automake
about the dependencies it (aclocal) has been able to figure out, so that
automake can emit make rules and dependencies that agrees with aclocal's
idea of dependencies.  This might be quite easy to implement, but before
giving it a try I'd like to hear Ralf opinion on the matter.

> I haven't tested this, but I suspect it also means that my workaround
> isn't going to cut it in the general case where foo.m4 uses or defines
> macros that aclocal needs to find.
Exactly.  And this too should be documented IMO.
 
> Nevertheless, if both aclocal and automake agreed on when to update
> aclocal.m4, then the "workaround" _would_ solve my specific problem.
As a side note, adding a new make variable (say `ACLOCAL_M4_DEPENDENCIES')
to let the user specify extra dependencies for aclocal.m4 could be helpful
for cases like yours.  Something similar is already done for `configure'
and `config.status' dependecies with respectively the make variables
`CONFIGURE_DEPENDENCIES' and `CONFIG_STATUS_DEPENDENCIES'.
 
> Thanks for your time on this matter,
And thanks for the time you spent reporting the problem and helping me
to understand it.

Regards,
   Stefano 



reply via email to

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