Howto fix KDE4 Buildsystem with CMake CVS

Brad King brad.king at kitware.com
Mon Jan 28 18:51:13 CET 2008


Andreas Pakulat wrote:
> On 28.01.08 16:04:06, David Faure wrote:
>> On Monday 28 January 2008, Andreas Pakulat wrote:
>>> Opinions? Better Ideas?
>> Does replacing -lsolid with ${KDE4_SOLID_LIBS} work?
>> After all we already have those variables, so we can avoid -lfoo completely I think.
> 
> Its not quite that easy. The thing is that -lsolid is produced my
> cmake's export_library_dependencies() function. So we'd have to find all
> uses of all KDE_XXX_LIBS variables that include -lsolid and then add
> KDE_SOLID_LIBS to the target_link_libraries() call.
> 
> And then again if compiling aborts with -lkparts or some other lib.

It looks like export_library_dependencies is misused a bit.  The command 
creates a file that contains lines like

   set(zot_LIB_DEPENDS "bar;foo")

When this is loaded into an outside project, that project may then write

   target_link_libraries(myexe zot)

and the link dependency analysis will see "zot" and load its 
dependencies out of the "zot_LIB_DEPENDS" variable automatically.  The 
resulting link line will contain

   ... -lzot -lbar -lfoo ...

Note that there is no explicit reference to ${zot_LIB_DEPENDS} anywhere.

It is up to the project that calls export_library_dependencies to 
produce a variable containing the link directory.  The user project 
should be able to do

   find_package(XXX REQUIRED)
   link_directories(${XXX_LIBRARY_DIRS})
   target_link_libraries(myexe zot)

The XXX package should provide settings for XXX_LIBRARY_DIRS and 
zot_LIB_DEPENDS.  The latter may be provided by loading the file created 
by export_library_dependencies.

The above is all documented in the "Mastering CMake" book with an 
example of handling exactly this case.

> Hmm, maybe export_libraries_dependencies could just generate absolute
> library paths instead of simply -l if the target is in the same cmake
> project.

I've actually been working on a new solution to this entire problem for 
the last couple of weeks.  CMake 2.6 will include the necessary 
features.  I haven't finished the documentation yet, but here is a taste 
of what how things will work.  The project exporting libraries will have 
code like

   add_library(mylib mylib.c)
   install(TARGETS mylib DESTINATION lib EXPORT myexp)
   install(EXPORT myexp DESTINATION lib/myproject)

Other projects will import libraries

   find_package(XXX REQUIRED) # module loads lib/myproject/myexp.cmake
   add_executable(myexe myexe.c)
   target_link_libraries(myexe mylib)

Under the hood, the install(EXPORT) command creates and installs the 
myexp.cmake file.  It contains code like:

   add_library(mylib IMPORTED)
   set_target_properties(mylib PROPERTIES
     IMPORTED_LOCATION "/path/to/lib/libmylib.a")

Then when the file is included in the other project the IMPORTED target 
"mylib" is created and can be referenced for linking like any other target.

-Brad


More information about the Kde-buildsystem mailing list