[Top][All Lists]
[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
- [PATCH] Improve support for non-default autotools in rebuild rules., Stefano Lattarini, 2010/08/12
- Re: [PATCH] Improve support for non-default autotools in rebuild rules., Stefano Lattarini, 2010/08/13
- Re: [PATCH] Improve support for non-default autotools in rebuild rules., Ralf Wildenhues, 2010/08/13
- Re: [PATCH] Improve support for non-default autotools in rebuild rules., Stefano Lattarini, 2010/08/13
- Re: [PATCH] Improve support for non-default autotools in rebuild rules., Ralf Wildenhues, 2010/08/13
- Re: [PATCH] Improve support for non-default autotools in rebuild rules., Stefano Lattarini, 2010/08/13
- Re: [PATCH] Improve support for non-default autotools in rebuild rules.,
Ralf Wildenhues <=
- [PATCH v2] Improve support for non-default autotools in rebuild rules., Stefano Lattarini, 2010/08/14
- Re: [PATCH v2.1] Improve support for non-default autotools in rebuild rules., Stefano Lattarini, 2010/08/14
- [PATCH v2.2] Improve support for non-default autotools in rebuild rules., Stefano Lattarini, 2010/08/15
- Closing the thread, Stefano Lattarini, 2010/08/18