On Jul 30, 2015, at 11:56 AM, Dan Kegel <d...@kegel.com> wrote: > > Am 30.07.2015 10:15 vorm. schrieb "Bill Hoffman" <bill.hoff...@kitware.com>: > > > > On 7/30/2015 10:48 AM, Dan Kegel wrote: > >> > >> I wouldn't mind getting rid of the cache, it's a bizarre concept that > >> appears > >> to be a workaround for users who can't stand starting cmake from a script, > >> and it complicates my cmake scripts, but that's not a battle I'd like to > >> wage. > > > > No, it is how CMake stores things it finds during the configure step. If > > you did not have it you would have to rediscover everything for every run > > on a build tree, and have no place to store user selections in the GUI. > > I believe the latter, but not the former. > I never use the GUI, and consider the cache an anti-feature there solely to > support GUI users. It complicates my life, and I'd love to see it go. >
Which don't you believe? The part where if you don't have a cache then you have to rediscover everything? Simply delete the CMakeCache.txt file and rerun CMake. You will rediscover everything. If you do not have some sort of "state file" then exactly how would one store their selections? Since you are comfortable on the command line I'll assume you love typing: cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr/foo -DCXX_COMPILE_FLAGS=All -DKEEP_GOING_WITH_EVEN_MORE_ARGUMENTS -G Ninja ../YourProject. For shorter invocations this isn't so bad to type. We have our project down to a single argument, but we preload from, wait for it, a cache file. But what about those folks who are simply NOT comfortable on the command line and always use the GUI? If CMake _never_ had a GUI then your argument might have some merit. If your next thought is something like ".. Well just write an alias in your .bashrc so you do not have to type it out each time.." then didn't you just basically create a "cache" file? And if you vote for "just rediscover everything, every time" then you have never run CMake on a larger project on a Windows machine with Visual Studio. Now _that_ is slow. I think the history of the design implementations kind of shows that a Cache is more helpful than hurtful. Plus when Project developers decide to hard code their own version of dependent libraries and give you no way of over riding those settings OTHER than hand editing the cache file, then be thankful you have the cache file there. Just my 2 cents. Mike Jackson
-- 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://public.kitware.com/mailman/listinfo/cmake
