Re: [PATCH] Improve support for non-default autotools in rebuild rules.

[Ralf Wildenhues]

* Stefano Lattarini wrote on Fri, Aug 13, 2010 at 07:38:13PM CEST:
> Hi Ralf.  Sorry you missed my last "drop this" message...

I didn't.  I just hoped the post might be helpful anyway.  Just ignore
it if it distracts you.

> At Friday 13 August 2010, Ralf Wildenhues wrote:
> > Why are you not suggesting AM_MISSING_PROG([AUTOM4TE], [autom4te])?
> Bacause `missing 'recognizes autom4te as special, and tries to work
> around it if it's broken or not avaiable; but I do not want this
> workaround to kick in when $AUTOM4TE is called by e.g. aclocal,
> since aclocal needs a real autom4te run anyway.

Why?  We don't fail either if aclocal is completely absent.

> Better to have
> a flat-out failure in this case.  Alas, something similar holds for
> autoconf-called-by-automake too, so the patch is bounded to become
> still messier...

I guess I fail to understand why the 63 rule should apply to one
situation but not the other.

> >  I guess I don't really see why searching for autom4te is somehow
> > a better a idea than finding out which autom4te autoconf actually
> > uses: that is, either $AUTOM4TE if set, or the thing that was
> > compiled in, which at least is guaranteed to match the Autoconf
> > version which autoconf comes from.
> Hmm...  this is right, and I started to realize it by myself also...
> Probably something likethis  would be enough:
>   test -z "$AUTOM4TE" && AUTOM4TE=autom4te
>   AC_SUBST([AUTOM4TE])

I'm not sure that is right, because configure doesn't know what's stored
as default in automake, autoconf, aclocal etc., so this might not be
what you wanted.

> Let's postpone further discussion until I post the updated patch, ok?

Sure.

Thanks,
Ralf