On Fri, 2005-06-03 at 09:37 +0200, Stepan Kasal wrote: > 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, Exactly. > even though their > configure.ac files might differ. Right, this is the troublesome spot. Such configure scripts must be carefully designed to interact properly on caches. Before autoconf-2.5x, sharing caches had been enabled by default, since autoconf-2.49 (IIRC) sharing caches has been disabled. > 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. This would mean, these configure scripts are not designed to properly interact. > Thus the general macros cannot use cache. Packages need to be designed/prepared for this to work. > 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. This is how they are supposed to work. Environment variables are supposed to override the cache. > 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 Nope. > A plan: > The current caching scheme in programs.m4 has serious problems and has > to be removed. That will significantly improve correctness. Which? I don't see them. Conversely, this scheme is almost as old as autoconf (I don't recall when they were introduces autoconf-2.8 or something) and many major packages apply it, so changing anything inside is dangerous. > (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.) Frankly speaking, I dislike this plan. Either autoconf should perform a clear cut, that is abandon caches entirely, which means autoconf will be totally incompatible to any former version of autoconf (a side-effect will be that autoconf will have to be versioned), or nothing should change in autoconf's behavior. Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
