Re: please correct my ugly hack

[Ralf Corsepius]

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