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

[Stefano Lattarini]

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