autoconf
[Top][All Lists]
Advanced

[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




reply via email to

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