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
