autoconf
[Top][All Lists]
Advanced

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

Re: problem with cached values


From: Ralf Wildenhues
Subject: Re: problem with cached values
Date: Wed, 10 Jan 2007 19:38:58 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Vincent,

* Vincent Torri wrote on Tue, Dec 26, 2006 at 06:39:27PM CET:
[...]
> I've installed STLport 5.1 in /usr/local. So, the first check (in /usr) 
> returns a warning, and then STLport is searched in /usr/local. The result 
> of the configure script is the following:
> 
> checking stl/config/user_config.h usability... no
> checking stl/config/user_config.h presence... no
> checking for stl/config/user_config.h... no
> configure: WARNING: STLport headers not in /usr/include/stlport
> checking for stl/config/user_config.h... (cached) no
> configure: WARNING: STLport headers not in /usr/local/include/stlport
> configure: error: "STLport is needed !"

> Can someone explain what the problem is, and then what kind of solution 
> there is to such problem ?

Autoconf caching assumes that AC_CHECK_HEADERS checks do not depend on
other state.  (This is at least somewhat reasonable: all other header
checks could change if you change CPPFLAGS after them.)

You have two ways to fix your macro:

1)
Put a
  unset ac_cv_header_std_config_user_config_h
before your test.

2)
Roll your own manual test (using AC_COMPILE_IFELSE, AC_PREPROC_IFELSE,
AC_LANG_PROGRAM etc.) that uses no caching or a manual form of
unambiguous caching.  

The first has the advantage of being simple, but the disadvantages of
being more expensive for rechecks (e.g., `./config.status --recheck'),
and a wee bit less portable, see 
<http://www.gnu.org/software/autoconf/manual/html_node/Limitations-of-Builtins.html#index-g_t_0040command_007bunset_007d-1259>.
But that's probably not a problem for you in practice.  In any case your
users will see an error if unset does not work.

The second solution is a bit more work.  ;-)

I think Eric covered the rest of your mail.

Cheers,
Ralf




reply via email to

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