Brad King wrote: > On 10/24/2013 12:56 PM, Stephen Kelly wrote: >> l -1 /home/stephen/dev/prefix/qtbase/kde/doc/ >> cmake-2.8/ >> cmake-2.8.12.20131023-g07324-dirty/ >> cmake-2.8.12.20131023-g10e02-dirty/ >> cmake-2.8.12.20131023-g1bfc2/ >> cmake-2.8.12.20131023-g3dec3/ > > The granular version-specific locations ensure we don't > get modules left over from a different version. This has > caused problems in the past that are very hard to track > down remotely.
If dealing with a user perhaps. Developers shouldn't have that problem. > This shouldn't be much of a problem for > anyone except developers. Then how about a compromise of major.minor.patch ? > IMO one shouldn't be overwriting an existing install tree > with a new CMake without removing the original anyway, but > this approach gives us protection from it. Managing > replace-able installations is the job of a package manager. > If you're doing it by hand IMO you're on you're own. > > FYI, I keep my test install tree below my build directory > and wipe it out before the next install: > > rm -rf $whatever_you_call_the_prefix > make install That doesn't work for me because my qtbase prefix is where I install qtbase dev branch and other Qt repos (also dev branch), cmake (master, a topic or whatever version I need to test the Qt cmake files with), some KDE stuff and some KDAB stuff. I have another prefix for qtbase stable branch testing/work, another for Qt 4.8 etc. Clearing one of those prefixes completely just to remove micro-versioned cmake installations is not practical, and I don't want to add another dimension to my prefix system just for cmake installations. Thanks, Steve. -- 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
