Wouldn't it then be possible to write a simple shell script for those people who really want that use case which calls cmake with -U and afterwards call cmake-gui? Sorry if I didn't understood it as it was ment.
For me the thing is: I prefer a simple solution which allows the same stuff which is possible with cmake itself (e.g. writing custom scripts which set default entries) and not to bloat the gui with stuff which are not used very often and can be achieved already with a combination of cmake/cmake-gui On Tue, Nov 5, 2013 at 9:40 PM, Matthew Woehlke <[email protected] > wrote: > On 2013-11-05 15:14, physhh . wrote: > >> On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke wrote: >> >>> On 2013-11-05 14:36, Alexander Neundorf wrote: >>> >>>> Once the cache is deleted in cmake-gui, I would expect that the >>>> values from the command line are also forgotten, also the -U >>>> values. Otherwise this cmake would remove the matching entries >>>> from every cache I load. >>>> >>> >>> True. (But what if that's what you want?) >>> >> >> Could you give me a use case where u actuall don't want this? As already >> stated are the command line parameters the "default" values. >> If I dont' want to remove an entry by default I won't pass that parameter. >> If I want to remove an entry (but not by default) I will do it with the >> gui >> itself - That's what the gui is for? >> > > The use case is invoking cmake-gui "by hand" from a command line for a > specific project (i.e. specifying the build directory also on the command > line). > > As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to > work more like that. Whereas folks that are used to doing everything from > GUI's and hardly if ever touch a command line want it to work like we're > suggesting. Both points of view are IMO valid (though I tend towards > greater sympathy for the latter in this case). > > (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and > TBH, ccmake much more than cmake-gui - but I (try to) understand and > respect the non-CLI use case.) > > (¹ ...though not nearly as much as some people I know. I do prefer kwin > and kdevelop over ratpoison and vim/emacs, thank you ;-).) > > > -- > Matthew > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
