I'm not sure if this will be useful, but there is info on the wxwidgets wiki regarding the use of cmake
http://wiki.wxwidgets.org/CMake Bill On Tue, Dec 23, 2008 at 1:05 PM, Robert Dailey <[email protected]> wrote: > On Tue, Dec 23, 2008 at 11:10 AM, Michael Jackson > <[email protected]> wrote: >> >> n Dec 23, 2008, at 11:56 AM, Bill Hoffman wrote: >> >>> Robert Dailey wrote: >>> >>>> For debug: C:\foo\bar-d >>>> For release: C:\foo\bar >>>> Note that the text "Debug" or "Release" is not used in the include path, >>>> so simply using CFG_INTDIR would not work I don't think (Unless I'm missing >>>> something again). This is why in CMake I need to do something like this: >>>> if( debug ) >>>> include_directories( C:\foo\bar-d ) >>>> else() >>>> include_directories( C:\foo\bar ) >>>> endif() >>>> Thanks again to everyone for their continued help. >>> >>> OK, well, since VS supports multiple configurations at VS time, and not >>> CMake time, it is impossible to have the above if statement. There is just >>> no way to know what configuration the user will pick. The user gets to >>> pick a long time after that if statement was executed by CMake. So, I think >>> you are sort of out of luck right now... What CMake needs is per >>> configuration include_directories for this to work. One thing that might >>> work as a work around, is that you could copy the header file via a custom >>> command into your build tree, and then use the CFG_INTDIR approach. >> >> I am just thinking out loud here so if I am totally off the mark just >> ignore. >> >> So the problem is including /foo/bar-d or /foo/bar for debug and release. >> >> For a release build there is the -NDEBUG definition and for Debug there is >> the -DEBUG compiler definitions defined (or something that at effect) >> >> In your own project have a header file (MySetup.h) with something like: >> >> #ifdef NDEBUG >> #include "bar/setup.h" >> #else >> #include "bar-d/setup.h" >> #endif >> >> Then you need to just have C:\foo on the include path. >> >> I _think_ something like that might work. Not sure how scalable or >> maintainable that might be since I have never used wxWidgets. > > This is a great idea but I can't do this, since I would have to edit > wxWidgets source files to make this work. For my own specific case I do not > want to edit third party libraries. However, again, this is a very valid > work around and would be usable in the typical case. > > _______________________________________________ > CMake mailing list > [email protected] > http://www.cmake.org/mailman/listinfo/cmake > _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
