Re: Strangeness with m4_include and aclocal.

[Nick Bowler]

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.

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

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

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.

Nevertheless, if both aclocal and automake agreed on when to update
aclocal.m4, then the "workaround" _would_ solve my specific problem.

Thanks for your time on this matter,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)