Philip Lowman a écrit :
On Mon, Dec 22, 2008 at 11:27 PM, Robert Dailey <rcdai...@gmail.com
<mailto:rcdai...@gmail.com>> wrote:
On Mon, Dec 22, 2008 at 9:23 PM, Bill Hoffman
<bill.hoff...@kitware.com <mailto:bill.hoff...@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@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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
