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