DEC
9
2005

a new way to build KDE applications

Hi,

in the screenshot you can see a different kpager than the one you know.

[image:1667]

So, what's different ?
This kpager is built from the same sources, but neither using autotools, nor unsermake, nor scons. It's built using cmake ( http://www.cmake.org ).
Here's how I did it:

hammer:~/src/kdecmake/samples$ svn co https://[email protected]:/home/kde/branches/KDE/3.5/kdebase/kpager
A  kpager/hi16-app-kpager.png
A  kpager/uninstall.desktop
A  kpager/kpager.desktop
A  kpager/hi48-app-kpager.png
A  kpager/config.cpp
A  kpager/windowdrag.cpp
A  kpager/kpagerIface.h
A  kpager/kpager.cpp
A  kpager/desktop.cpp
A  kpager/config.h
A  kpager/windowdrag.h
A  kpager/kpager.h
A  kpager/desktop.h
A  kpager/main.cpp
A  kpager/TODO
A  kpager/Makefile.am
A  kpager/hi22-app-kpager.png
A  kpager/hi32-app-kpager.png
 U kpager
Checked out revision 487266.
hammer:~/src/kdecmake/samples$ cd kpager
hammer:~/src/kdecmake/samples/kpager$ am2cmake
hammer:~/src/kdecmake/samples/kpager$ cmake .
-- Check for working C compiler: gcc
-- Check for working C compiler: gcc -- works
-- Check size of void*
-- Check size of void* - done
-- Check for working CXX compiler: c++
-- Check for working CXX compiler: c++ -- works
-- Looking for XOpenDisplay in /usr/X11R6/lib/libX11.so;/usr/X11R6/lib/libXext.so
-- Looking for XOpenDisplay in /usr/X11R6/lib/libX11.so;/usr/X11R6/lib/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/src/kdecmake/samples/kpager
hammer:~/src/kdecmake/samples/kpager$ make
Generating desktop.moc
Generating kpager.moc
Generating config.moc
Generating kpagerIface_skel.kidl
Generating kpagerIface_skel_skel.cpp
Scanning dependencies of target kpager
Building CXX object CMakeFiles/kpager.dir/desktop.o
Building CXX object CMakeFiles/kpager.dir/kpager.o
Building CXX object CMakeFiles/kpager.dir/config.o
Building CXX object CMakeFiles/kpager.dir/windowdrag.o
Building CXX object CMakeFiles/kpager.dir/main.o
Building CXX object CMakeFiles/kpager.dir/kpagerIface_skel_skel.o
Linking CXX executable kpager
hammer:~/src/kdecmake/samples/kpager$ ./kpager
ERROR: kpager is already running!
hammer:~/src/kdecmake/samples/kpager$    

So what did I do ? I checked out only kpager from kdebase and then ran the am2cmake script in it, which "translated" the Makefile.am to the CMakeLists.txt as required by cmake. Then cmake runs and creates the Makefiles. Finally make is invoked and builds kpager. When it's finished, kpager was started. But since there was already a kpager running it complains and exits.

Wanna know how the CMakeLists.txt created by am2cmake looks like ? Here it is (slightly edited to use less space and some comments added):

# needed for finding Qt, KDE and the tools like moc, etc.
include(../../FindKDE3.cmake)
include(../../KDE3Macros.cmake)

# add the current directory to the include path
include_directories( ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR}  )

# list the source file
set(kpager_SRCS desktop.cpp kpager.cpp config.cpp windowdrag.cpp main.cpp )

# automoc, more to say ?
kde3_automoc(${kpager_SRCS})

# generate the dcop stuff
kde3_add_dcop_skels(kpager_SRCS  kpagerIface.h )

# create the binary named kpager from the sources listed in kpager_SRCS
kde3_add_executable(kpager ${kpager_SRCS})

# and link it to qt, kdecore and kdeui
target_link_libraries(kpager  ${QT_AND_KDECORE_LIBS} kdeui )

# install kpager into the bin/ dir relativ to the installation directory
install_targets(/bin kpager )

# install the desktop file
install_files( /share/applications/kde FILES kpager.desktop )

# install the icons
kde3_install_icons( hicolor )

If you ask me, building KDE applications hasn't been that easy for a long time now.
After some more polishing I'll try to get the am2cmake script and the FindKDE3.cmake included in cmake, so that everybody will have them available when installing cmake.
Maybe I'll also try my luck on KDE4.

Bye
Alex

Comments

Hi!
I just used auto* based build systems so far on Linux.
I've seen the imake-stuff of XFree before and I know those project files generated by MS VC on Win*.
They all are incompatible to each other.
So here's my question:
Why should we use another build system for KDE, after it has been decided to switch to scons (IIRC)?
Which advantage does cmake have over it's competitors like auto* and scons?
I don't want to keep you from experimenting with cmake and KDE (or whatsoever), I just wonder if the work you do is usefull for KDE or you just did it in your spare time to play a little with it.


By Christian Nitschkowski at Sat, 12/10/2005 - 17:57

the kde build system is made for well... kde... its current incarnation is insane for apps not in the KDE revision control. why does my 100k app need 2.1mb of autocrap? This is where things like cmake, qmake and other build systems will make our lives easier.

that said, im a qmake fanboy, so i ask "why does KDE need scons?" ;)


By Ian Reinhart Geiser at Mon, 12/12/2005 - 03:29

Hi,

Ian is right. I never understood autohell, and I tried to learn it several times. I read articles like "how to libtoolize your application", it lead me nowhere.
Now with cmake I'm for the first time since a long long time ago able to build a KDE application and understand how it the build works. This is different from copying the autotools stuff from some project, replace some things and then hope that it will work and be lost if it doesn't.
From the concept cmake is quite similar to qmake (a binary application which reads text files and produces build files).
Differences to qmake:
cmake is
-not related to Qt
-more extendible than qmake (I think)
-easy to use (as qmake is)
-can not only generate Makefiles, but also XCode, MSVC and KDevelop3 projects

I also tried scons some time ago, but I didn't really like it. Of course it is better than autotools. But I didn't want to learn a full scripting language (python). I didn't want to write a program to build my program. cmake is simple and has a limited syntax, so it is easy to learn.

Right now I'm trying my cmake-KDE3 stuff with several applications/libs/parts/ioslaves/etc. from KDE svn, to see how well it works. (most things work automatically with the autotranslated CMakeLists.txt).

Alex


By Alexander Neundorf at Mon, 12/12/2005 - 09:46