caching behavior

[Alexander Neundorf]

On Tuesday 17 November 2009, David Faure wrote:
> 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! ;)

Usually I'm happy if it compiles and I don't even get so far to run 
something...

> > 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

I set CMAKE_PREFIX_PATH usually as environment variable.

> -DCMAKE_LIBRARY_PATH=/d/kde/inst/kdesupport_trunk/lib
> -DCMAKE_INCLUDE_PATH=/d/kde/inst/kdesupport_trunk/include

You don't need these two. CMAKE_PREFIX_PATH should do it all, if it doesn't, 
we need to fix the respective file(s).

> -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

The thing is, there are not only initial options with cmake. You can run cmake 
with one option, then run cmake-gui and change some settings, e.g. enable 
KDE4_BUILD_TESTS, etc. 
Rerunning cmake just with the initial command line would not have these manual 
modifications done later on.

> 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

I saw on the cmake list that cmake-gui in cmake 2.8.0 now has something to 
help with that, i.e. to show which things have been manually changed or which 
were preset or something. But I did not yet actually look at it myself.

> script, but personally I think interactive usage is more for "fixing stuff
> up" than for long-term options that should be replayed when reconfiguring.

Well, it's for adjusting the build to your liking if there are more options 
than what you'd like to enter on the command line. Then these settings should 
be kept.
We are discussing the case that the cache has been removed and how to get to 
the same results again, right ?
Actually I'd really recommend to not remove the cache, but use cmake-gui 
(or "make edit_cache") and just remove what you want to have removed. If 
there are issues with cmake-gui, or something which makes it inconvenient for 
you to use, please report it in the cmake bug tracker.

Alex