autoconf
[Top][All Lists]
Advanced

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

Re: please correct my ugly hack


From: Stepan Kasal
Subject: Re: please correct my ugly hack
Date: Fri, 3 Jun 2005 09:37:33 +0200
User-agent: Mutt/1.4.1i

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




reply via email to

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