Why I need this feature is irrelevant, the important thing is that I need the feature. I know a couple of other people who've posted on various other mailing lists that have asked for this as well.
However, if you must know, I need this mainly because of wxWidgets. wxWidgets has a setup.h file that is located in a directory specific to the configuration in which wxWidgets was built. For the respective configuration, I need to tell the compiler to use a different setup.h, which means I need to specify a different include directory per configuration. There's other ways to solve this problem other than using include directories, but this is the most trivial and simplified way. On Tue, Dec 23, 2008 at 5:00 AM, cyril_wobow <cy...@wobow.com> wrote: > 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
