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

[Stefano Lattarini]

Hi Ralf.  Sorry you missed my last "drop this" message...

At Friday 13 August 2010, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Thu, Aug 12, 2010 at 07:00:08PM CEST:
> > Note that I have not yet run the whole testsuite on this change;
> > I will if you tell me you're interested in the patch.
> 
> I'm intrigued by the fact that there appears to be a bug in the
> current implementation.  I agree with you in finding the patch not
> exactly clean.  ;-)
And also broken, in fact :-(

> 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.  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 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])
(with a short explanatory comment extracted from your considerations).

> And from a user standpoint,
> I'm sure some would be surprised to see their configure script
> search for a behind-the-scenes tool they never knew was being used
> at all.
But it does that with autoconf already, doesn't it?  Moreover, a 
failure in finding autom4te doesn't cause an error, unless autom4te is 
really used at some point. Anyway, tihs is a moot point given what 
said above...
 
> Of course, with AM_MISSING_PROG there is still the problem that I
> think neither of autoconf, autoheader, ..., aclocal, automake are
> prepared for a return value of 63 from autom4te, which should
> probably let them return 63 as well.  Haven't checked though.
Let's postpone further discussion until I post the updated patch, ok?
Might be by tomorrow hopefully...

Thanks
  Stefano