Development/CMake KDE 4 2 - Revision history

Mck182: Fix typos (where -> were)

2013-05-11T16:19:09Z

Fix typos (where -> were)

Neundorf: /* How to install libraries correctly now */

2009-01-12T22:57:55Z

‎How to install libraries correctly now

Neundorf: /* Set the link interface */

2009-01-12T22:54:03Z

‎Set the link interface

Neundorf: /* New: The reduced link interface */

2009-01-12T22:53:44Z

‎New: The reduced link interface

Neundorf: /* Export the library */

2009-01-11T21:02:33Z

‎Export the library

Tampakrap at 16:30, 11 January 2009

2009-01-11T16:30:19Z

Neundorf: /* How to use libraries from kdebase/workspace/ */

2009-01-11T16:22:48Z

‎How to use libraries from kdebase/workspace/

Neundorf: /* Specifying the minimum required version of some package */

2009-01-11T12:20:40Z

‎Specifying the minimum required version of some package

Neundorf: /* Guide for writing CMake files */

2009-01-11T12:20:11Z

‎Guide for writing CMake files

Neundorf: /* Other Changes */

2009-01-11T12:10:33Z

‎Other Changes

@@ Line 89: / Line 89: @@
 ===New: The reduced link interface===
-In KDE 4.0 and 4.1 EXPORT_LIBRARY_DEPENDENCIES() was used in kdelibs/ and kdepimlibs/ for the installed libraries. This creates a file which lists all libraries of that project, and against which libraries they link. This file then had to be include()d by other projects. This way those projects transitively also linked against ''all'' libraries against which these libraries where linked when using these libraries. This is called the "link interface".
+In KDE 4.0 and 4.1 EXPORT_LIBRARY_DEPENDENCIES() was used in kdelibs/ and kdepimlibs/ for the installed libraries. This creates a file which lists all libraries of that project, and against which libraries they link. This file then had to be include()d by other projects. This way those projects transitively also linked against ''all'' libraries against which these libraries were linked when using these libraries. This is called the "link interface".
 Here's an example:
 <pre>
@@ Line 156: / Line 156: @@
 ===Removed option: KDE4_USE_ALWAYS_FULL_RPATH===
-KDE4_USE_ALWAYS_FULL_RPATH was by default on. In this case executables, libraries and plugins where linked with RPATH. This caused relinking of these binaries during make install, which takes some time. If it was off, only executables where linked with RPATH, and their RPATH had to be sufficient also for the shared libraries and plugins. This can be the case, but doesn't have to.  Applications which were not marked as RUN_UNINSTALLED where built directly with their install RPATH. This saved a lot of time during make install but the resulting install might not get the correct libraries. Since version 2.6 CMake can now edit the RPATH inside binaries, which compared to relinking takes no time.
+KDE4_USE_ALWAYS_FULL_RPATH was by default on. In this case executables, libraries and plugins were linked with RPATH. This caused relinking of these binaries during make install, which takes some time. If it was off, only executables were linked with RPATH, and their RPATH had to be sufficient also for the shared libraries and plugins. This can be the case, but doesn't have to.  Applications which were not marked as RUN_UNINSTALLED were built directly with their install RPATH. This saved a lot of time during make install but the resulting install might not get the correct libraries. Since version 2.6 CMake can now edit the RPATH inside binaries, which compared to relinking takes no time.
 That's why this option is not necessary anymore, and now '''all''' executables, libraries and plugins are always built with their build tree RPATH and then installed with their install tree RPATH, so they always get their correct libraries, both when executed from the build tree as well as when executed from the install tree.

@@ Line 110: / Line 110: @@
 ===How to install libraries correctly now===
-If a project installs a library, and creates an exported target for it, which can be imported by other projects then, two things have to be done additionally:
+Libraries are still installed using INSTALL(TARGETS ...).
 # Set the link interface
 # Export the target
 ====Set the link interface====

@@ Line 121: / Line 121: @@
 kde4_add_library(kfoo ${kfooSrcs})
 target_link_libraries(kfoo ${ZLIB_LIBRARIES} ${QT_QTGUI_LIBRARY})
-target_link_libraries(kfoo LINK_INTERFACE ${QT_QTGUI_LIBRARY})
+target_link_libraries(kfoo LINK_INTERFACE_LIBRARIES ${QT_QTGUI_LIBRARY})
 </pre>

@@ Line 101: / Line 101: @@
 add_library(foo ${fooSrcs})
 target_link_libraries(foo ${BAR_LIBS} ${BLUB_LIBS} ${ZOT_LIBS})
-target_link_libraries(foo LINK_INTERFACE ${BLUB_LIBS})
+target_link_libraries(foo LINK_INTERFACE_LIBRARIES ${BLUB_LIBS})
 install(foo EXPORT MyExports DESTINATION lib ...)

@@ Line 126: / Line 126: @@
 ====Export the library====
-This is done in two steps. First add the library to a set of exported targets, and then install this export set as explained above. Here you chose the name ''MyExports'' for the export set:
+This is done in two steps. First add the library to a set of exported targets, and then install this export set as explained above. Here we chose the name ''MyExports'' for the export set:
 <pre>
 kde4_add_library(kfoo ${kfooSrcs})

@@ Line 97: / Line 97: @@
 </pre>
-When then another project loads this file and links something against foo, it will be also linked against BAR_LIBS, BLUB_LIBS and ZOT_LIBS. While this is necessary for static libraries, it is not necessary for everything for shared libraries. For shared libraries only those libraries should be in the link interface, which are exposed in the public interface of the library. If e.g. foo uses class BlubWidget in a public header, BLUB_LIBS should be in the link interface. This is done using the TARGET_LINK_LIBRARIES() command. The link interface set there is not considered when using EXPORT_LINK_LIBRARIES(), but it is used when exporting the target. So in order to actually benefit from the link interface, the export feature has to be used:
+When then another project loads this file and links something against foo, it will be also linked against BAR_LIBS, BLUB_LIBS and ZOT_LIBS. While this is necessary for static libraries, it is not necessary for everything for shared libraries. For shared libraries only those libraries which are exposed in the public interface of the library should be in the link interface. If e.g. foo uses class BlubWidget in a public header, BLUB_LIBS should be in the link interface. This is done using the TARGET_LINK_LIBRARIES() command. The link interface set there is not considered when using EXPORT_LINK_LIBRARIES(), but it is used when exporting the target. So in order to actually benefit from the link interface, the export feature has to be used:
 <pre>
 add_library(foo ${fooSrcs})

@@ Line 40: / Line 40: @@
 ===How to use libraries from kdebase/workspace/===
-In kdebase/workspace/ there are several libraries which are installed and can be used by other projects. These are libraries for kwin, plasma, the screensaver and some more, see the documentation at the top of kdelibs/cmake/modules/FindKDE4Workspace.cmake for the full list of variables (they are all prefixed with "KDE4_WORKSPACE_" ).
+In kdebase/workspace/ there are several libraries which are installed and can be used by other projects. These are libraries for kwin, plasma, the screensaver and some more, see the documentation at the top of kdelibs/cmake/modules/FindKDE4Workspace.cmake for the full list of variables (they are all prefixed with "KDE4WORKSPACE_" ).
 ===New: Exporting and importing targets===

@@ Line 179: / Line 179: @@
 </pre>
 This works, but there is one problem when doing this for finding KDE4: this way to specify the version is not supported by KDE 4.0/4.1, they just ignore this version information. So to make sure this also works with KDE 4.0/4.1 you have to use the KDE_MIN_VERSION variable.
-Not modules should support only the new way to do it.
 ===Misc. new CMake features===

← Older revision		Revision as of 12:20, 11 January 2009
Line 164:		Line 164:

	And there is also a guide on how to keep source compatibility for CMake FindXXX.cmake modules: [[Policies/CMake_and_Source_Compatibility \| Source compatiblity with CMake]]		And there is also a guide on how to keep source compatibility for CMake FindXXX.cmake modules: [[Policies/CMake_and_Source_Compatibility \| Source compatiblity with CMake]]
		+
		+	===Specifying the minimum required version of some package===
		+
		+	With KDE 4.0/4.1 the minimum required version of some package could by specified using module-specific variables. E.g. for the minimum version of kdelibs you had to do the following:
		+
		+	<pre>
		+	set(KDE_MIN_VERSION "4.1.0")
		+	find_package(KDE4 REQUIRED)
		+	</pre>
		+
		+	Now with CMake 2.6 the FIND_PACKAGE() command supports a minimum version directly as first argument after the package name, but it also has to be supported by the respective FindXXX.cmake module. So now you can do:
		+	<pre>
		+	find_package(KDE4 "4.2" REQUIRED)
		+	</pre>
		+	This works, but there is one problem when doing this for finding KDE4: this way to specify the version is not supported by KDE 4.0/4.1, they just ignore this version information. So to make sure this also works with KDE 4.0/4.1 you have to use the KDE_MIN_VERSION variable.
		+	Not modules should support only the new way to do it.

	===Misc. new CMake features===		===Misc. new CMake features===

@@ Line 17: / Line 17: @@
 At least version 2.6.2 of CMake is required now. With KDE 4.0 and 4.1 version 2.4.5 was required.
 ===How to use KdepimLibs===
@@ Line 154: / Line 133: @@
 install(EXPORT MyExports args_see_above... )
 </pre>
 ===Guide for writing CMake files===