Thanks for the detailed answer Philip. I was able to get around this for my case by the feature included with target_libraries(<debug | optimized>) - luckily that's exactly what I needed. I understand what you're saying, maybe I can add an entry to the cmake wikipedia about it,
Thanks, Mark On 10/21/07, Philip Lowman <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Wyszomierski wrote: > > Hi Mike, > > > > When I try CMAKE_BUILD_TYPE MATCHES Debug, it seems to never execute > > the contents of that IF statement (as if I am never CMake'ing a DEBUG > > build?). > > > > I don't know if CMAKE_BUILD_TYPE is the same thing as what's in the > > CMAKE_CONFIGURATION_TYPES field. I really need something like: > > > > IF (CMAKE_CONFIGURATION_TYPE MATCHES Debug) > > // include some library.... > > ELSE > > // ... > > ENDIF > > > > I'm not sure if that's the same thing? > > One common misconception (about CMake) is that it's always capable of > doing what you think it should be doing. :) Part of the problem lies > in the fact that CMake tries to support both "single configuration type" > and "multiple configuration type" build tools simultaneously. > > The Makefile generator only supports one configuration type at a time > (Debug, Release, etc.) which works out very nice as variables like > CMAKE_BUILD_TYPE can be read at CMake time and used to change the > configuration of the build. Take the following code for example... > > project(FOO) > if(CMAKE_BUILD_TYPE MATCHES Debug) > INCLUDE_DIRECTORIES(bar) > else(CMAKE_BUILD_TYPE MATCHES Debug) > INCLUDE_DIRECTORIES(top) > endif(CMAKE_BUILD_TYPE MATCHES Debug) > ADD_EXECUTABLE(foo foo.cc) > > Should do exactly what you want to do... When you set the > CMAKE_BUILD_TYPE cache variable to Debug your Makefiles will add "bar" > to the include path and vice versa if you don't define it. > > When you use a "multiple configuration types" generator like Visual > Studio, however, the CMAKE_BUILD_TYPE variable will no longer exist. > There is a hidden variable as you've discovered called > CMAKE_CONFIGURATION_TYPES but this only describes the types of > configurations which will show up in Visual Studio. There is no > scripted support for dynamically changing project files to do different > things using the "configuration type" of choice. > > You can introduce your own CACHE variables that change execution of > CMake to do whatever you want but it would not work through the multiple > build configuration feature of Visual Studio. You would basically have > to use CMake to generate one solution files and then another set. > > There is limited support via the use of SET_TARGET_PROPERTIES to modify > per configuration options that will work in Visual Studio but it's > limited. Take the following which would change your generated ".exe" or > ".lib" file for the target: > > SET_TARGET_PROPERTIES(foo PROPERTIES DEBUG_OUTPUT_NAME foodebug) > SET_TARGET_PROPERTIES(foo PROPERTIES RELEASE_OUTPUT_NAME foorelease) > > So the short answer is, the code people post to the mailing list may or > may not do what you want it to do... it all depends on what generator > you are using. Sorry for any confusion, all of this probably should be > documented somewhere in a "CMake gotchas" section. > > - -- > Philip Lowman > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHG9vZe0tOktX6RKkRAgJdAJwOSJXBcZwWAaPvtIPRpx+n/KVfVACfQaYI > WVxF4ILsE4/q3ZjZBc6vMwM= > =LfyP > -----END PGP SIGNATURE----- > _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake