On 11/06/2011 09:27 AM, Michael Wild wrote: > On 11/05/2011 09:59 PM, Michael Hertling wrote: >> On 11/02/2011 05:36 PM, Michael Wild wrote: >>> Thanks ;-) >>> >>> Michael >> >> Just an additional remark: Instead of generating the proxy headers >> in CMakeLists.txt, i.e. at configuration time, one might also have >> them generated by a custom command, i.e. at build time, which has >> the $<CONFIGURATION> expression available. E.g., one might use a >> CMake script invoked by the custom command via -P with -DCONFIG= >> $<CONFIGURATION>, and within this script, one could do arbitrary >> things based on the CONFIG parameter, i.e. linking/copying real >> headers, generating proxy headers with or without #ifdefs etc. >> In this way, one can gather the entire machinery in the script >> and does not need to do the case differentiation in the header >> itself, triggered via COMPILE_DEFINITIONS_<CONFIG> properties. >> Besides, with the custom command's DEPENDS clause, the actions >> can be set up to re-take place if any prerequisite has changed. >> >> Regards, >> >> Michael >> > > Indeed, that would be a more sophisticated way of doing it, but it > requires maintaining a separate CMake script. Some might consider this > to be a drawback, other an advantage as it declutters the CMakeLists.txt > file.
IMO, the premier advantage of a CMake script handling configuration- specific tasks at build time is that one can do what can be done in CMakeLists.txt files only for single-configuration generators: IF(CONFIG STREQUAL ...) ... ELSEIF(CONFIG STREQUAL ...) ... ELSE() ... ENDIF() In particular, the ELSE() clause can easily catch configurations - also custom ones - one doesn't want to handle specifically. In order to do the same in a CMakeLists.txt file and in a generator-independent way, one would need to do FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES ITEMS ${CMAKE_BUILD_TYPE}) IF(i STREQUAL ...) ... ELSEIF(i STREQUAL ...) ... ELSE() ... ENDIF() ENDFOREACH() and w.r.t. properties like COMPILE_DEFINITIONS_<CONFIG>, one would need an additional STRING(TOUPPER ...) because the configurations are named "Debug", e.g., while the property must be named *_DEBUG. Moreover, for proxy headers, one must essentially still do the case differentiation again in the header itself, e.g. #if defined(CONFIG_DEBUG) #include ... #elif defined (CONFIG_RELEASE) #include ... #else #include ... #endif using additional definitions CONFIG_*, instead of simply saying #include "@...@" in conjunction with CONFIGURE_FILE(... @ONLY) in the CMake script. For these reasons, I think that CMake scripts triggered by custom commands are generally more expressive in this regard, but of course, the main point is that one has the choice. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake