Re: Strangeness with m4_include and aclocal.

[Stefano Lattarini]

On Friday 22 October 2010, Nick Bowler wrote:
> On 2010-10-22 20:43 +0200, Stefano Lattarini wrote:
> > May I ask you that, the next time you report a problem, you also tell which
> > version of aclocal/automake are you using, and post the content of all the
> > relevant files (or reduced exemples thereof)?  That would make it easier
> > for us to understand and reproduce the reported issues.  Thanks.
> 
> Will do.
Thanks, much appreciated.

> Using aclocal-1.11.1 and automake-1.11.1.  Here's the
> configure.ac, with the MY_INC stuff commented out:
> 
>   AC_INIT([test], [1.0])
>   AM_INIT_AUTOMAKE([foreign])
>   
>   dnl AC_DEFUN([MY_INC], [m4_include([$1])])
>   dnl MY_INC([foo.m4])
>   AC_DEFUN([MY_INC2], [m4_apply([m4_include], [[$1]])])
>   MY_INC2([foo.m4])
>   
>   AC_CONFIG_FILES([Makefile])
>   AC_OUTPUT
> 
> Makefile.am and foo.m4 are empty files.
OK, similar enough to what I had hypothesized.  So far, so good.

> >   AC_DEFUN([MY_INC], [m4_include([$1])])
> [...]
> >   aclocal: error: configure.ac:1: file `$1' does not exist
> > 
> > I currently have no idea of why this is happening
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).

My explanation seems to be confirmed by the fact that substituting:
  AC_DEFUN([MY_INC], [m4_include([$1])])
with the equivalent (on m4 level at least):
  AC_DEFUN([MY_INC], [m4_][include([$1])])
makes the error above disappear.

Also, it explaines this other problem noticed by you:
> On another note: the following also fails in configure.ac:
> 
>   m4_ignore([m4_include([a_file_that_does_not_exist.m4])])
> 
> % autoreconf
>   aclocal: error: configure.ac:4: file `a_file_that_does_not_exist.m4' does 
> not exist
This error too disappers when one uses e.g.:
 m4_ignore([m4_][include([a_file_that_does_not_exist.m4])])
instead.

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.

> > (but luckily you have a workaround, so this should not be such a big
> > problem for you ATM).
> 
> Well, the workaround just replaces one problem (aclocal spits an error)
> with another (make tries to rebuild aclocal.m4 needlessly).  Not really
> perfect.
Hmm... I thought that git automake solved the second problem (needless
rebuilding of aclocal.m4), but you tell me it does not.  So let's see...
 
> > > So I tried to avoid this by being a little trickier:
> > > 
> > >   AC_DEFUN([MY_INC2], [m4_apply([m4_include], [[$1]])])
> > > 
> > > Now aclocal works properly, but the makefiles generated by automake do
> > > not: if the m4_included file is newer than aclocal.m4, 'make' will
> > > attempt to regenerate aclocal.m4 by calling aclocal.  Since aclocal.m4
> > > isn't actually out of date, aclocal does nothing and aclocal.m4 isn't
> > > updated.  Thus, every 'make' invocation will run aclocal needlessly.
> >
> > I can reproduce and confirm this problem with Automake 1.11, but luckily
> > it *seems* to have been fixed in developement version from git master
> > branch, probably with commit `v1.11-17-g333c18a' by Ralf Wildenhues.
> 
> I just tried with git master, it still seems to be present.
I re-tried, and now I *can* reliably reproduce the bug.  I probably messed
up something in my previous attempt.  Sorry for the noise, and thanks for
persisting.

> This is with the above configure.ac (commands prefixed with %, some
> output redacted):
> 
> % automake --version
>   automake (GNU automake) 1.11a
>   [...]
> % autoreconf -fi
>   [...]
> % ./configure
>   [...]
> % make
>   make: Nothing to be done for `all'.
> % touch foo.m4
> % make
>   [...]
> % make 
>   CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /scratch_space/actest/missing 
> --run aclocal-1.11a
>   make: Nothing to be done for `all'.
> % make
>   CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /scratch_space/actest/missing 
> --run aclocal-1.11a
>   make: Nothing to be done for `all'.
> % touch aclocal.m4 configure config.status Makefile Makefile.in
> % make
>   make: Nothing to be done for `all'.
> 
> > I'm out of time right now, but maybe tomorrow I might be able to check
> > that it really was that commit that fixed that problem; and if it is so,
> > your report might become a nice testsuite addition, ensuring that we do
> > not regress again in this matter.
> [...]
> > The failure in your second example was probably due to timestamp issues
> > (I'd classify it as a minor bug in automake).  I still have no idea why
> > your first example fails; I might try to dig deeper in the next days (if
> > nobody beats me ;-). 
> 
> The Makefile has the dependency:
> 
>   am__aclocal_m4_deps = $(top_srcdir)/foo.m4 $(top_srcdir)/configure.ac
> 
> 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 ...
> However, the aclocal program itself decides not to update aclocal.m4
> when 'make' runs it.
... as you noticed here.

So I consider the second problem reported by you as a real, albeit
minor, aclocal bug.  It should either be fixed, or documented as a
limitation in the Automake manual.  I'll see if I can manage to (try
to) fix it these days.

Thanks again for your report,
   Stefano