[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: Fri, 22 Oct 2010 17:55:11 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

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, with the MY_INC stuff commented out:

  AC_INIT([test], [1.0])
  dnl AC_DEFUN([MY_INC], [m4_include([$1])])
  dnl MY_INC([foo.m4])
  AC_DEFUN([MY_INC2], [m4_apply([m4_include], [[$1]])])
  AC_OUTPUT and foo.m4 are empty files.

>   AC_DEFUN([MY_INC], [m4_include([$1])])
>   aclocal: error: 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

> > 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 (commands prefixed with %, some output

% 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
% 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)/

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


% autoreconf
  aclocal: error: file `a_file_that_does_not_exist.m4' does not 

Nick Bowler, Elliptic Technologies (

reply via email to

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