Notes
(0006756) Bill Hoffman (manager) 2007-03-13 13:34	The problem is that deleting the cache may not be enough. Once you do an in-source run of cmake .h files and all other sorts of generated files maybe sitting in the build tree which happens to be the source tree. You really have to go back to a clean source tree to be safe. It is very hard for cmake to determine all the files that maybe generated into the build tree, and so it would be hard/ impossible to remove them.

(0006757) Brandon Van Every (reporter) 2007-03-13 13:47	If "delete cache" works 80% of the time for most builds, I'd say it's a good thing to tell newbies to do. And then having the button right there is a good idea on CCMake. At present, OSG users are learning they can "hack around" the problem by deleting the cache. It makes CMake look like it doesn't handle stuff. I think the perception is worthwhile if it's an 80% solution.

(0006758) Brandon Van Every (reporter) 2007-03-13 13:51	Also people coming from a GNU Autoconf culture are into deleting config.cache on the command line. Telling Autoconf users they can delete caches is good marketing.

(0006761) Bill Hoffman (manager) 2007-03-13 14:57	If it is what the OSG folks want to use it for, it will work for much less than 80% of the cmake projects. As soon as you have a configured header file you are going to have trouble, and you need to remove that as well. If you want to remove the cache so you can "fool" cmake into thinking this is a clean source tree so you can then create an out of source build that uses the same source tree, then you are going to put back the CMakeCache.txt file into the source tree it will cause all sorts of trouble. If you want to remove the cache so that you can re-compute all the try-compile stuff then it will work.

(0006767) Brandon Van Every (reporter) 2007-03-13 15:20	Could CMake, in principle, detect that it has already generated in-source configuration files? Like when told to do an out-of-source CONFIGURE_FILE, it checks whether an in-source CONFIGURE_FILE of the same name already exists. I realize CONFIGURE_FILE isn't actually aware of whether its directories are in-source or out-of-source, it just takes absolute pathnames that the user constructs somehow. But it should be possible to deduce an in-source directory by analyzing its 2 directory arguments. The 1st arg gives us the likely in-source directory root, and the 2nd arg vies us the likely in-source directory structure and file location, assuming the out-of-source tree is parallel. I think this would work most of the time, and the point is only to give a warning. If there are 2-3 typical issues with changing from in-source to out-of-source, that could be detected with not much work, and would get the bulletproofing up to the 80%..90% level, that would be a win.

(0006780) Bill Hoffman (manager) 2007-03-13 15:44	So, what are you suggesting? If cmake could detect any in-source configured files, do not allow delete cache? Or if you detect in-source configured files do not allow an out-of-source build?

(0006784) Brandon Van Every (reporter) 2007-03-13 17:14	I suggest, if CMake detects any in-source configured files, and the user hits "delete cache," warn the user that the in-source configured files still exist and can mess up their build. Use a dialog box for this. This should be an acceptable interruption, as if they pressed "delete cache," then they are a human being using the GUI, not an automated script. I would also suggest that such warnings be issued on the status line and the logs during the build. They shouldn't interrupt the build however.

(0006785) Bill Hoffman (manager) 2007-03-13 17:28	I still don't think this would solve the OSG issue. But a delete cache would not be a bad idea for ccmake. But, I don't think we need any warnings or have to detect any files that have been configured. The reason for deleting the cache is so that cmake will re-run all the try compile stuff. It is not used so that you can build in source and out of source. For that the use case would be awkward at best. Run ccmake , delete the cache, exit ccmake because if you run it again you will get another cache. Then run ccmake in a different directory to get the out of source build. Seems like a complicated way to say rm CMakeCache.txt.

(0006786) Brandon Van Every (reporter) 2007-03-13 18:09	How best to educate the user on the subject of in-source vs. out-of-source builds probably needs a different feature request. I think parallelism between CMakeSetup and CCMake is sufficient justification here.

(0041348) Kitware Robot (administrator) 2016-06-10 14:27	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2007-08-23 13:54	Alex Neundorf	Category	CMake => CCMake
2016-06-10 14:27	Kitware Robot	Note Added: 0041348
2016-06-10 14:27	Kitware Robot	Status	assigned => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:30	Kitware Robot	Status	resolved => closed

Relationships