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
