[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: please correct my ugly hack
From: |
Stepan Kasal |
Subject: |
Re: please correct my ugly hack |
Date: |
Thu, 2 Jun 2005 21:04:06 +0200 |
User-agent: |
Mutt/1.4.1i |
Hi Ralf,
On Wed, Jun 01, 2005 at 07:08:08PM +0200, Ralf Corsepius wrote:
> On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
> > Caching was invented mainly for expensive tests which involve
> > calling a compiler, which can be really slow.
> No, caching had been invented for faster interaction of several
> configure scripts (CONFIG_SUBDIRS) in large source trees.
Oh, I haven't considered/known this.
(But again, only expensive checks should be cached; in most environments,
AC_*PROG is relatively inexpensive.)
> > I think the best solution is to drop caching from programs.m4.
> Only over my dead body ;-)
I still hope to convince you without causing you any hurt. ;-)
Yes, I agree, caching is good.
But caching doesn't help, if it is not transparent.
In other words, FOO and ac_cv_prog_FOO are duplicates. (FOO itself acts as
a caching variable; if it is nonempty, the macro is skipped.)
But users change FOO themselves, without taking ac_cv_prog_FOO into
account and that brings the unwanted suprises.
(BTW, Claudio has told me that he experienced one of the surprises I
mentioned in my answer to his post; so this is a real-life problem.)
If mere ``export FOO'', as proposed by Dan, is not enough, then I have
another idea:
Let's say that ac_cv_prog_FOO is an ``alias'' to FOO.
How to implement it?
It's relatively easy: just before writing the cache, we'd do:
ac_cv_prog_FOO=$FOO
for each FOO which have been used as the first parameter to an AC_*PROG* macro.
(I said "have been" as the list of these variables has to be created during the
run of configure, if we adapt programs.m4 to use AS_VAR_*, so that non-literal
variable names are allowed.)
And at the beginning, just after the cache file and config.site were read,
we'd do
FOO=$ac_cv_prog_FOO
for all ac_cv_prog_* variables read from the cache.
I believe this would be a transparently working caching mechanism for AC_PROG
type macros.
The question is: is this worth it? Is the setup with "slow directories" so
common? How commonly are CONFIG_SUBDIRS used? (I admit I haven't any
experience with this feature, yet.)
Ralf, it would be easier, if you could _live_ with programs.m4 without
caching.
Perhaps we could put the above sketch of ``alias variables'' to a comment
near the top of programs.m4. As soon as real performance problems appear,
we'd implement it. (I propose this because I still think that the old
caching scheme in programs.m4 is unusable, and should be removed.)
Happy caching, ;-)
Stepan
- Re: please correct my ugly hack, (continued)
- Re: please correct my ugly hack, Stepan Kasal, 2005/06/01
- Re: please correct my ugly hack, Paul Eggert, 2005/06/01
- Re: please correct my ugly hack, Ralf Corsepius, 2005/06/01
- Re: please correct my ugly hack, Dan Manthey, 2005/06/01
- Re: please correct my ugly hack, Ralf Corsepius, 2005/06/02
- Re: please correct my ugly hack, Stepan Kasal, 2005/06/02
- unset variables, was Re: please correct my ugly hack, Dan Manthey, 2005/06/02
- Re: unset variables, was Re: please correct my ugly hack, Paul Eggert, 2005/06/03
- Re: unset variables, was Re: please correct my ugly hack, Stepan Kasal, 2005/06/03
- Re: unset variables, was Re: please correct my ugly hack, Dan Manthey, 2005/06/03
- Re: please correct my ugly hack,
Stepan Kasal <=
- Re: please correct my ugly hack, Stepan Kasal, 2005/06/03
- Re: please correct my ugly hack, Ralf Corsepius, 2005/06/03
- Re: please correct my ugly hack, Stepan Kasal, 2005/06/03
- Re: please correct my ugly hack, Ralf Corsepius, 2005/06/03
- Re: please correct my ugly hack, Bob Friesenhahn, 2005/06/03
- Re: please correct my ugly hack, Stepan Kasal, 2005/06/04
- Re: please correct my ugly hack, Ralf Wildenhues, 2005/06/05