automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralf Wildenhues
Subject: Re: [PATCH] Improve support for non-default autotools in rebuild rules.
Date: Sat, 14 Aug 2010 07:16:50 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

* Stefano Lattarini wrote on Sat, Aug 14, 2010 at 01:18:14AM CEST:
> At Friday 13 August 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Fri, Aug 13, 2010 at 07:38:13PM CEST:
> > > 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

Are you describing here how the current code behaves or how you think it
should behave?

> (JFTR, `missing' is IMHO useful, but it's also a mixed blessing).

Sure it has downsides.  It allows the end user to build some piece of
code even if the tarball/vcs checkout has messed up time stamps and the
regeneration tools are missing.  With downsides for the developer who
then has to take more care while working on the code.

> > > 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.

You can configure Autoconf with, say, --program-prefix=-2.67, and that
will cause autoconf to contain code like
  AUTOM4TE=${AUTOM4TE-autom4te-2.67}

Now, when $AUTOM4TE is unset at the time package foo is configured, and
foo has the code you suggest above, then that AUTOM4TE=autom4te will
break a perfectly working setup.

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]