caching behavior

[David Faure]

On Tuesday 17 November 2009, Alexander Neundorf wrote:
> Which -D options do you need ? I usually only need CMAKE_INSTALL_PREFIX
>  and  maybe CMAKE_BUILD_TYPE.

What?? You don't set KDE4_BUILD_TESTS? Bad boy! ;)

> If you need many more options in many cases, maybe something else needs to
>  be  changed.

I pass 

-DCMAKE_INSTALL_PREFIX=/d/kde/inst/kde-trunk
-DKDE4_BUILD_TESTS=TRUE 
-DCMAKE_BUILD_TYPE:STRING=debugfull
-DCMAKE_PREFIX_PATH:PATH=/d/kde/inst/kdesupport_trunk
-DCMAKE_LIBRARY_PATH=/d/kde/inst/kdesupport_trunk/lib 
-DCMAKE_INCLUDE_PATH=/d/kde/inst/kdesupport_trunk/include
-DPYTHON_SITE_PACKAGES_DIR=~/.local/lib/python2.6/site-packages
(and of course the path to the source dir)

So yes, I definitely see a point in having a way to ask cmake to "rerun itself 
with the initial options, after discarding the cache". Pretty much what
"rm config.cache; ./config.status" would do in the autoconf world.

Right now I use kdesvn-build --reconfigure to do this, for kde modules,
and for everything else I keep a "mycmake.sh" file which runs cmake with
the right options, but this is all too much manual bookkeeping. If only cmake 
would generate a config.status equivalent which contained the initial 
invokation, one could easily "rerun cmake without its cached values, just
with the values explicitely set by the user".

cmake-gui and ccmake would either break that, or would have to modify that
script, but personally I think interactive usage is more for "fixing stuff up" 
than for long-term options that should be replayed when reconfiguring. No 
strong opinion on that though.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).