[cmake-developers] unexpected cmake cache behaviour

[Brad King]

Alexander Neundorf wrote:
> Hi,
> 
> the cache behaviour of cmake is a bit unexpected (2.4 branch here).
> 
> Take the following CMakeLists.txt:
> 
> find_path(STDIO_H stdio.h)
> 
> and run cmake on it.
> It will produce an entry "STDIO_H" in CMakeCache.txt.
> Then run cmake again, but give a value for STDIO_H:
> 
> cmake . -DSTDIO_H=foo
> 
> For that run cmake will use "foo" as value for STDIO_H, but it won't go into 
> the cache. Instead the entry STDIO_H disappeared completely from 
> CMakeCache.txt, so when running make the next time cmake will not know what 
> to use for STDIO_H.
> 
> Then run cmake again, and specify the type:
> 
> cmake . -DSTDIO_H:STRING:foo
> 
> Now it will go in the cache with the value foo.
> 
> IMO that this doesn't happen for the second case is maybe a bug, but at least 
> uncomfortable behaviour. Is this intended this way ?
> It seems this is the code in cmCacheManager which implements the behaviour:
> 
>     if(t == cmCacheManager::UNINITIALIZED || !ce.Initialized)
>       {
>       /*
>         // This should be added in, but is not for now.
>       cmSystemTools::Error("Cache entry \"", (*i).first.c_str(),
>                            "\" is uninitialized");
>       */
>       }
> 
> Last week in Trysil at the KDE Four Core meeting I learned that the KDE devs 
> are a bunch of tough guys, happily hand-editing CMakeCache.txt and entering 
> lines like 
> cmake ...some/dir -DCMAKE_INSTALL_PREFIX=/opt/kde4 -DKDE4_IGNORE_DONTPORT=TRUE 
> without bitching.
> But requiering to enter 
> cmake ...some/dir -DCMAKE_INSTALL_PREFIX:PATH=/opt/kde4 
> -DKDE4_IGNORE_DONTPORT:BOOL=TRUE
> seems like a bit much.
> I'd suggest either to default to STRING or at least reuse the type from the 
> cache for the new value.

I'll try to investigate this situation when I get a chance.  We
generally use CMakeSetup or ccmake and have not had to deal with the
problem.

-Brad