[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

Here is what happens:

The option -DSTDIO_H=foo replaces any loaded cache entry with

  STDIO_H:UNINITIALIZED=foo

in memory.  The FIND_PATH command sees that STDIO_H is already set in
the makefile and does nothing.  Then cmCacheManager::SaveCache avoids
writing the value to the cache because its type is UNINITIALIZED.

On the other hand CMAKE_INSTALL_PREFIX works properly.  This is because
it is created by the SET command, which gives the value a type without
changing the value.  If we modify your example:

FIND_PATH(STDIO_H stdio.h)
SET(STDIO_H "STDIO_H-NOTFOUND" CACHE PATH "Location of stdio.h.")

it works as expected because the SET command provides the type and then
cmCacheManager::SaveCache saves the value.  The value given to the SET
command does not really matter.

The bug is in cmFindPathCommand and cmFindBase.  The AlreadyInCache
check prevents the command from ever setting the type and documentation
properly.

-Brad