[Top][All Lists]

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

Re: Strangeness with m4_include and aclocal.

From: Nick Bowler
Subject: Re: Strangeness with m4_include and aclocal.
Date: Wed, 27 Oct 2010 09:10:30 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

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

> > so it believes that aclocal.m4 is out of date when foo.m4 is updated.
> And this is right, because includes foo.m4, and since
> aclocal.m4 depends on all the content of, *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 (

reply via email to

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