[CMake] including paths - basic

[Mark Wyszomierski]

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 <philip at yhbt.com> 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-----
>