Re: Strangeness with m4_include and aclocal.

[Nick Bowler]

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

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

> > 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.  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.
However, the aclocal program itself decides not to update aclocal.m4
when 'make' runs it.

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

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)