[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: please correct my ugly hack

From: Ralf Corsepius
Subject: Re: please correct my ugly hack
Date: Fri, 03 Jun 2005 14:34:35 +0200

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,

>  even though their
> 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 files can contain AC_CHECK_PROGS([DUMP], ...),
> with a totally different meanings.
This would mean, these configure scripts are not designed to properly

> 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

> 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.


reply via email to

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