* 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
