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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
