Hello again, I'm sorry that I post a followup to my own mail: On Thu, Jun 02, 2005 at 09:04:06PM +0200, Stepan Kasal wrote: > On Wed, Jun 01, 2005 at 07:08:08PM +0200, Ralf Corsepius wrote: > > No, caching had been invented for faster interaction of several > > configure scripts (CONFIG_SUBDIRS) in large source trees. So the subprojects can share the cache, even though their configure.ac files might differ. The consequences: 1) I proposed: > Let's say that ac_cv_prog_FOO is an ``alias'' to FOO. [...] > just before writing the cache, we'd do: ac_cv_prog_FOO=$FOO This would be incorrect. The cache would be affected by the skew which ca be added by each configure script. 2) Two configure.ac files can contain AC_CHECK_PROGS([DUMP], ...), with a totally different meanings. Thus the general macros cannot use cache. But the checks for particular programs (AC_PROG_AWK, AC_PROG_CC, etc.) can cache their findings. There is still one problem: The variable itself has to have higher priority than its cache shadow. Currently, AC_PROG_AWK is something like AC_CACHE_VAL([ac_cv_prog_AWK], [if test "x$AWK" = x; then ... ; fi]) but it should be: if test "x$AWK" = x; then AC_CACHE_VAL([ac_cv_prog_AWK], [...]) fi A plan: The current caching scheme in programs.m4 has serious problems and has to be removed. That will significantly improve correctness. (I could get to that approx in July, I guess.) Then the caching can be added back to the particular checks, if anyone cares. (For specific setups, this will increase the speed again.) Have a nice day, Stepan Kasal _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
