aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRalf Habacker <ralf.habacker@freenet.de>2009-05-26 10:54:50 +0000
committerRalf Habacker <ralf.habacker@freenet.de>2009-05-26 10:54:50 +0000
commitb3c2e3ff4e329cdc24e3275aaeb61cd4e0525a31 (patch)
treed90d40e505247fc3056e1670fd4fb17eb486a161
parent47deb33eb4acf0d48476eb07cf7ab0e3a187b580 (diff)
downloadextra-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.cmake23
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})