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, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem