[CMake] Add configuration support to include_directories()

[cyril_wobow]

Philip Lowman a écrit :
> On Mon, Dec 22, 2008 at 11:27 PM, Robert Dailey <rcdailey at gmail.com 
> <mailto:rcdailey at gmail.com>> wrote:
>
>     On Mon, Dec 22, 2008 at 9:23 PM, Bill Hoffman
>     <bill.hoffman at kitware.com <mailto:bill.hoffman at kitware.com>> wrote:
>
>
>                Investigate CMAKE_CFG_INTDIR.
>
>
>             I believe for Visual Studio output, this will be
>             $(OutDir), right? If this is the case, this is a visual
>             studio environment variable that will have no meaning when
>             used in CMake scripts.
>
>
>         It is . when not in VS, and $(OutDir) when it is.  So, you can
>         say /foo/bar/bin/${CMAKE_CFG_INTDIR}/runit.
>
>         It will be /foo/bar/bin/./runit with makefiles.
>         It will be /foo/bar/bin/$(OutDir)/runit with VS projects.
>
>
>     Keep in mind this is for include directories, which will not work
>     with visual studio environment variables. I need to statically
>     tell CMake which include directories go along with what
>     configuration. I don't believe this can be done at the moment, at
>     least with visual studio generation.
>
>
> Just curious, why would you ever want to have two different include 
> directories, one for debug and one for release?  It doesn't seem like 
> a very good idea to me, but then again perhaps there is a good use 
> case for this.  How many header files are affected?  I assume you are 
> aware of and have rejected using the NDEBUG definition for your 
> problem (via a 3rd wrapper file for every affected header file)
>
> -- 
> Philip Lowman
> ------------------------------------------------------------------------
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

Hi

That sounds funny. Each time I see a question about "how to do something 
configuration-specifically when generating for visual studio" it ends up 
"why on earth would you want to do that?". I guess it proves one more 
time that visual studio users expect every feature that cmake provides 
at configuration-time to also be provided at pre-build time. Thanks to a 
lot of cmake scripting, I have managed to get something like that to 
work but it is true that some features are still not utilizable 
configuration-specifically.
(Last critical thing for me was how to tell cmake which CMAKE_BUILD_TYPE 
is "debug" and which is "optimized", which is why I am bound to use 
cmake from cvs where Brad King introduced a DEBUG_CONFIGURATIONS global 
property).
I am really interested ni cmake developers' feelings about that.

Cyril