[cmake-developers] unexpected cmake cache behaviour

[Alexander Neundorf]

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.

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net