[Cmake] Combining Separate CMake Projects

[Brad King]

Chris Scharver wrote:
> On Jun 28, 2004, at 3:23 PM, Brad King wrote:
> 
>>> For now, I want to avoid copying all the data files to a new 
>>> location. It's a lot easier for now to just place the binaries at the 
>>> appropriate place in the source tree. I'm happy to see that 
>>> INSTALL_TARGETS works on Windows now! I am encountering a strange 
>>> issue with CMAKE_INSTALL_PREFIX now. In my top-level CMakeLists.txt, 
>>> I have:
>>> MARK_AS_ADVANCED(CLEAR CMAKE_INSTALL_PREFIX)
>>> SET(CMAKE_INSTALL_PREFIX ${project_SOURCE_DIR})
>>> When I start the CMake GUI (2.0-2), this variable appears as 
>>> /usr/local. However, when I build the install project in Visual 
>>> Studio, the targets are installed into the correct directory! The 
>>> CMakeCache.txt still contains /usr/local, and if I uncomment the 
>>> lines above, the targets are installed into C:/usr/local. Something 
>>> doesn't seem to match between the GUI and the interpreted value 
>>> during the install. Is there some way that I can set the 
>>> CMAKE_INSTALL_PREFIX in CMakeLists.txt and have the GUI reflect the 
>>> updated value?
>>
>>
>> The SET command you are using just sets the variable for the CMake 
>> configure phase.  The cache file is used only to initialize these 
>> values.  To set it in the cache you need to call the SET command in a 
>> special way.  See the cmake documentation for the proper form of the 
>> command:
> 
> 
> Using FORCE is the only way that I can have the CMakeLists.txt update 
> CMAKE_INSTALL_PREFIX so that it has the correct value the first time 
> that the user runs CMake. However, this means that the GUI then cannot 
> be used to change the value since each configuration FORCEs it to the 
> value from the config. My intuition lead me to think that setting the 
> variable in CMakeLists.txt would initialize the value for the first 
> configuration. cmLocalGenerator::GenerateInstallRules() always seems to 
> initialize CMAKE_INSTALL_PREFIX to "/usr/local" unless I have FORCEd it 
> to something else, and that doesn't seem correct. Consider the following 
> very simple CMakeLists.txt:
> 
> PROJECT(FOO)
> SET(CMAKE_INSTALL_PREFIX "C:/foo" CACHE PATH "Foo install path")
> ADD_TARGET(foo foo.c)
> INSTALL_TARGETS(/ foo)
> 
> Shouldn't this mean that installing defaults to placing foo.exe into 
> C:/foo? Instead, the project creates C:/usr/local. I can FORCE the 
> variable, but then users cannot change the value without changing either 
> CMakeLists.txt or CMakeCache.txt. Or am I looking at the install process 
> in the wrong way? Maybe a custom move command would be more appropriate 
> in this case?

As of CMake 2.0 there is a way to deal with this problem.  Put a file 
called PreLoad.cmake in the top of your project's source tree.  Put code 
like this in the file:

IF(WIN32)
   IF(NOT CYGWIN)
     SET(CMAKE_INSTALL_PREFIX
         "$ENV{SystemDrive}/Foo" CACHE PATH "Foo install path")
   ENDIF(NOT CYGWIN)
ENDIF(WIN32)

This file is read before the first CMake configure step ever occurs, so 
you can use it to put defaults in the cache.

-Brad