current state of using cmake to compile kdevelop

[Alexander Neundorf]

Hi,

since some weeks I'm trying to compile kdevelop using cmake (since I only find 
once or twice per weeks a few hours to work on it it takes some time...).

So, what's the current state:
The whole kdevelop module compiles and links.
I'm currently in the process of adding the install rules

There are some issues (all solved or solvable):

1) there is a very kdevelop-specific problem related to cmake: in kdevelop 
there exists the binary "kdevelop" and the library "libkdevelop.so". Since in 
cmake all libs are only referenced by the actual name (i.e. without prefix 
and suffix) libkdevelop is also only "kdevelop" in cmake. So when I simply 
wrote
TARGET_LINK_LIBRARY(kdevpropeditor kdevelop) 
which should link the executable kdevpropeditor to libkdevelop.so, cmake got 
slightly confused and started to build the executable kdevelop.
TARGET_LINK_LIBRARY(kdevpropeditor ${CMAKE_BINARY_DIR}/lib/libkdevelop.so) 
works for now, but is not nice.
Either cmake has to be changed so that it can handle this situation better or 
libkdevelop.so or the kdevelop binary would have to be renamed 
(libkdevplatform.so ?)

2) there are some directories (e.g. kdevprojectmanager) where binaries or 
shared libs link to a libraries in one of its subdirectories.
This is currently a small problem for cmake, if the executable would be built 
in a directory "parallel" to the lib then cmake could handle the library 
dependencies better. I'm waiting for an answer from the cmake-guys to this 
issue.

3) libtool convenience libraries
cmake doesn't really support "convenience" static libraries, i.e. libs which 
are included completely when linked to an application or a shared library.
I implemented a small workaround so that it is possible to build static libs 
which behave the same way. This would have to be extended for platforms other 
than linux. 
Or maybe even better just get rid of the convinience libs and simply compile 
the sources from the subdirectories directly into the shared libs. Would 
there be a problem with this ? 

4) plugins
KDE loads plugins using libltdlopen. This seems to depend on the libtool la 
files. I don't know much about these files. I implemented a cmake macro which 
produces files which look similar to "real" la-files. 
They also contain an entry "dependency_libraries". I'm not sure what to insert 
there. The original la-files among others also list other la-files in this 
entry. Is this necessary ?

5) I have not yet written any configure checks. What should be checked ? In 
which directories ?

A typical CMakeLists.txt - file currently looks like this:

---------8<------------8<--------------8<

#list the sources
SET(kdevabbrev_PART_SRCS 
    abbrevpart.cpp abbrevconfigwidget.cpp addtemplatedlg.cpp )

#list the ui files
SET(kdevabbrev_UI
    abbrevconfigwidgetbase.ui addtemplatedlgbase.ui )

#generate rules for the moc files
KDE_AUTOMOC(${kdevabbrev_PART_SRCS})

#generate rules for the ui files
KDE_ADD_UI_FILES(kdevabbrev_PART_SRCS ${kdevabbrev_UI} )

#most important line: build a library
ADD_LIBRARY(kdevabbrev MODULE ${kdevabbrev_PART_SRCS})

#link some libs to libkdevabbrev.so
TARGET_LINK_LIBRARIES(kdevabbrev ${KDEV_PART_LIBS})

#macro for creating the libtool la file
KDE_CREATE_LIBTOOL_FILE(kdevabbrev)

#install the library
INSTALL_TARGETS(/lib/kde3/lib kdevabbrev)

----------8<---------------8<------------8<------------

More stuff could be integrated into cmake macros (e.g. to recognize the suffix 
of the input files and automatically call the MOC and UI macros on them, 
adding the install rules automatically etc.) But IMO adding more magic 
doesn't always mean it gets easier to understand.

Bye
Alex
-- 
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org                - http://www.kde.org
      alex at neundorf.net               - http://www.neundorf.net