Re: Broken makefile given Autoconf version mismatch

[Stepan Kasal]

Hello,

On Fri, Apr 21, 2006 at 10:55:01AM +0200, Ralf Wildenhues wrote:
> * Stepan Kasal wrote on Fri, Apr 21, 2006 at 10:40:04AM CEST:
> > > This would silently break lots of `bootstrap' scripts that call
> > >   aclocal
> > >   automake
> > >   autoconf
> > 
> > It wouldn't break them, I think, it would only slow them down.
> > During the first `make', automake would update all Makefile.in's and
> > the build would continue.  But yes, it wouldn't be nice.
> 
> I believe you assume too much.  You assume that, at the time `make' is
> called, the autotools are available and the same versions as at the time
> `bootstrap' is called; also, that the source tree is writable at `make'
> time; [...]

yes, I'm assuming all of that.  If I were to do a build from a read-only
tree, I would first create a tarball by `make dist', and that `make dist'
would update all the Makefile.in's.

> also assume that the user won't start to issue `make' in several build
> trees at once? [...]

And if I were to run several VPATH builds in parallel, I'd definitely use
a read-only source tree, to prevent conflicts.  Hence I'd create a tarball,
too.

> also, that `AM_MAINTAINER_MODE' is not in effect.

I don't think this would matter here.  If AM_MAINTAINER_MODE is in
effect, the depedency of Makefile.in on $(top_srcdir)/configure would
be suppressed, so it wouldn't matter that configure is newer than
Makefile.in.

But yes, I always tend to assume that no one uses AM_MAINTAINER_MODE.  ;-)

> And even with those assumptions I'd call that breakage: the bootstrap
> script stops to perform its main function, namely to ensure that the
> autotools have been run properly.

OK, I adopt your position, it would be a breakage.

So we have yet another reason why Alexandre's solution is superior.

Have a nice day,
        Stepan