Re: Strangeness with m4_include and aclocal.

[Stefano Lattarini]

On Thursday 28 October 2010, Stefano Lattarini wrote:
> 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.
> 
Ping on this?

Reference to original thread:
 <http://lists.gnu.org/archive/html/automake/2010-10/msg00036.html>

Regards,
  Stefano