[CMake] debug/optimized include directories

Michael Hertling mhertling at online.de
Mon Nov 7 17:17:57 EST 2011


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


More information about the CMake mailing list