At Friday 13 August 2010, Ralf Wildenhues wrote: > * 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. And it is. The "sorry" was addressed to you ("sorry if I made you waste your time on this"); but if you think your time wasn't wasted, it's all for the best. > Just ignore it if it distracts you. It doesn't -- it helps me in fact.
> > 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. Yes, and this is justified IMO. But if aclocal proper is ever called, it needs a working autom4te to get traces from e.g. configure.ac, and the workaround provided by `missing --run autom4te' is not enough in such a case (JFTR, `missing' is IMHO useful, but it's also a mixed blessing). > > 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. Hmm... well, if automake/aclocal had been installed, they should have been configured to use already-present autoconf and autom4te programs, so your objection makes sense... I need to think more about this, probably. But then again, if e.g. the default autoconf used by automake is not modern enough for our configure.ac, while the $AUTOCONF passed to ./configure is, I think the automake calls in the rebuild rule should force the use of that modern-enough $AUTOCONF... and we need a way to discriminate when $AUTOCONF must truly been overriden for the automake calls... tricky. A good and precise testcase is needed here, definitely. > > > 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., Why not? AM_INIT_AUTOMAKE ensures at least a `missing' wrapper for each of them, doesn't it? But probably I'm not undrstanding your objection... clarifications are welcome. > so this might not be what you wanted. > > > Let's postpone further discussion until I post the updated patch, > > ok? > Sure. Patch hopefully to come (sorta soonish) tomorrow... Thanks, Stefano