Re: aclocal.m4 not regenerated when Makefile.am changes

[Colin Watson]

On Sun, Feb 17, 2008 at 06:48:07PM +0100, Ralf Wildenhues wrote:
> * Colin Watson wrote on Sun, Feb 17, 2008 at 04:23:32PM CET:
> > In a fresh unpacked copy of
> > http://download.savannah.nongnu.org/releases/man-db/man-db-2.5.1.tar.gz:
> > 
> >   $ touch Makefile.am
> >   $ ./configure
> >   $ make
> >   configure.ac:7: version mismatch.  This is Automake 1.10.1,
> >   configure.ac:7: but the definition used by this AM_INIT_AUTOMAKE
> >   configure.ac:7: comes from Automake 1.10.  You should recreate
> >   configure.ac:7: aclocal.m4 with aclocal and run automake again.
> >   WARNING: `automake-1.10' is probably too old.  You should only need it if
> >            you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
> >            You might want to install the `Automake' and `Perl' packages.
> >            Grab them from any GNU archive site.
> > 
> > Of course, I have upgraded automake on my system to 1.10.1 since
> > producing that tarball. But why didn't the rebuild rules just run
> > aclocal for me? This seems as simple as adding Makefile.am to the
> > dependencies of $(ACLOCAL_M4).
> 
> But normally, aclocal.m4 does not need to be regenerated when
> Makefile.am is updated.  What you would really need in your case is a
> dependency of aclocal.m4 on /usr/bin/aclocal-1.10.
> 
> Since we don't have dependencies on installed packages, pragmatically
> the best thing to do when you update system tools is to run autoreconf.

Mm. I don't rely on the rebuild rules myself, of course; I have an
autogen.sh script which calls autoreconf and a few other things. The
reason I noticed this was in the context of ensuring that users get
Makefile.in et al automatically upgraded if they need to change
Makefile.am for some reason. I can arrange that they have at least some
required version by way of a version number in AM_INIT_AUTOMAKE, but I
can't arrange that they have exactly the same version I have.

> > If nothing else, Makefile.am may contain ACLOCAL_AMFLAGS (and in fact
> > does in this case), so IMO correct rebuild rules should re-run aclocal
> > in case those flags changed;
> 
> Good point.  I don't know how to formulate this without making a blanket
> dependency on Makefile.am, though; and that would, for the vast majority
> of use cases, be much more work than is normally needed.  Users would
> complain about this.

I see; fair point. I don't suppose it would be possible for automake,
when it would normally emit the message quoted above, to run aclocal
itself and then re-exec itself, perhaps with a guard against an infinite
loop?

> > although in order to get that completely
> > right it also ought to fish ACLOCAL_AMFLAGS out of Makefile.am à la
> > autoreconf ...
> 
> This does happen though, when the aclocal rule is executes: it has
>         $(ACLOCAL) $(ACLOCAL_AMFLAGS)

That's the previous value of ACLOCAL_AMFLAGS, though (the one in place
when automake and configure were last run), rather than the current one
in Makefile.am.

Thanks,

-- 
Colin Watson                                       address@hidden