diff options
author | Ralf Habacker <ralf.habacker@freenet.de> | 2009-05-26 10:54:50 +0000 |
---|---|---|
committer | Ralf Habacker <ralf.habacker@freenet.de> | 2009-05-26 10:54:50 +0000 |
commit | b3c2e3ff4e329cdc24e3275aaeb61cd4e0525a31 (patch) | |
tree | d90d40e505247fc3056e1670fd4fb17eb486a161 | |
parent | 47deb33eb4acf0d48476eb07cf7ab0e3a187b580 (diff) | |
download | extra-cmake-modules-b3c2e3ff4e329cdc24e3275aaeb61cd4e0525a31.tar.gz extra-cmake-modules-b3c2e3ff4e329cdc24e3275aaeb61cd4e0525a31.tar.bz2 |
documented the real problem better
svn path=/trunk/KDE/kdelibs/; revision=973034
-rw-r--r-- | modules/KDE4Macros.cmake | 23 |
1 files changed, 18 insertions, 5 deletions
diff --git a/modules/KDE4Macros.cmake b/modules/KDE4Macros.cmake index eadf5708..d02e0c55 100644 --- a/modules/KDE4Macros.cmake +++ b/modules/KDE4Macros.cmake @@ -792,17 +792,30 @@ endmacro (KDE4_ADD_UNIT_TEST) # add a manifest file to executables. This macro is used by kde4_add_executable # -# In cmake <= 2.6.4 there is a bug which returns a wrong path from -# get_target_property(var <target_name> LOCATION), when the -# OUTPUT_NAME property of a target is set before. +# There is a henn-egg problem when a target runtime part is renamed using +# the OUTPUT_NAME option of cmake's set_target_properties command. +# +# At now the Makefiles rules creating for manifest adding are performed +# *after* the cmake's add_executable command but *before* an optional +# set_target_properties command. +# This means that in KDE4_ADD_MANIFEST the LOCATION property contains +# the unchanged runtime part name of the target. :-( # -# To workaround those cases a specific variable should be set before -# calling kde4_add_executable as shown by the following example: +# The recently used workaround is to specify a variable build off the target name followed +# by _OUTPUT_NAME before calling kde4_add_executable as shown in the following example: # # set(xyz_OUTPUT_NAME test) # kde4_add_executable( xyz <source>) # set_target_properties( xyz PROPERTIES OUTPUT_NAME ${xyz_OUTPUT_NAME} ) # +# The full solution would be to introduce a kde4_target_link_libraries macro and to +# call KDE4_ADD_MANIFEST inside instead of calling in kde4_add_executable. +# This would require patching of *all* places in the KDE sources. where target_link_libraries +# is used and to change the related docs. +# +# Because yet I found only 2 locations where this problem occurs (kjs, k3b), the workaround +# seems to be a pragmatically solution. +# macro (KDE4_ADD_MANIFEST _target_NAME) set(x ${_target_NAME}_OUTPUT_NAME) if (${x}) |