Correction, that email somehow got corrupted wrt the newlines. These should be on two separate lines:
Set(EXE_DEF "somedef") #executable defs Set(LIB_DEF "somedef") #library def overrides Sorry about that, Luke -----Original Message----- From: Luke Kucalaba Sent: Friday, October 10, 2008 1:46 PM To: 'Bill Hoffman' Cc: cmake@cmake.org Subject: RE: [CMake] Running cmake multiple times to resolve cache variables Thanks Bill, I understand exactly what you are talking about. I looked into our cmake project structure, and ran some tests. I think we originally started out using a sequentially correct organization, but we ran into problems with the Include_Directories() command passing down the include directories to each subdirectory, when we really want a subdirectory to be treated as a completely stand-alone module (for instance, an independent static library project). The other problem is that the CMAKE_CONFIGURATION_TYPES variable doesn't seem to get applied unless you run cmake a second time (we only want to have Debug and Release configurations in MSVC71). You are completely correct in that we needed to reorganize our project structure. I came up with a workaround for the include directories problem. This was our old sequence (required two passes): Add_Subdirectory(LIB) #load library project Set(EXE_DEF "somedef") #executable defs Set(LIB_DEF "somedef") #library def overrides Include_Directories() #set include directories for exe Add_Executable(EXE) Target_Link_Libraries(EXE LIB) Add_Dependencies(EXE LIB) Here is our sequence now (only needs one pass): Set(EXE_DEF "somedef") #executable defs Set(LIB_DEF "somedef") #library def overrides Add_Subdirectory(LIB) #load library project Include_Directories() #set include directories for exe Add_Executable(EXE) Target_Link_Libraries(EXE LIB) Add_Dependencies(EXE LIB) By putting the Include_Directories() after the Add_Subdirectory() it prevented the unwanted behavior. Still don't know how to set the build configurations with CMAKE_CONFIGURATION_TYPES using a single pass, but other than that this seems to be working with one pass. Thanks for your help :-D Luke -----Original Message----- From: Bill Hoffman [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2008 12:42 PM To: Luke Kucalaba Cc: cmake@cmake.org Subject: Re: [CMake] Running cmake multiple times to resolve cache variables Luke Kucalaba wrote: > I think the reason we need to run cmake.exe multiple times is because we > typically have a "main" project that automatically sets the options of > dependent projects. For example, our main executable project has an > option "ENABLE_NETWORKING", which then triggers automatic changes for > various global CACHE variables that are used in subdirectories > (sub-projects) that have already been processed (using CACHE STRING > FORCE). This requires the user to run cmake.exe again to reprocess > those subdirectories. Is this not something that we should be doing? > Or am I not understanding how the multiple passes of cmake works? > > Luke I still don't get your problem. The use of CACHE FORCE is usually a bad idea. A CMake project should not need to be run twice to work correctly. Basically, you have created cmake files that do not use the correct order of evaluation. Here is one example of that: add_library(foo ...) # I use SOME_LIB before it is set target_link_library(foo ${SOME_LIB}) # Now I add a sub directory A, that sets SOME_LIB as a cache variable add_subdirectory(A) A: set(SOME_LIB mylib CACHE FORCE) This would require two runs of cmake to get the value of SOME_LIB correct in the toplevel cmake file. Basically, if your project requires double runs of CMake, then it has a bug. -Bill _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
