Build system for KDE4

[Alexander Neundorf]

Hi,

On Tuesday 14 June 2005 06:26, Thiago Macieira wrote:
> Alexander Neundorf wrote:
> >>  - icon installation
> >
> >needs a custom macro (not yet written)
>
> How easy is it to add such macro? How can it be shared among KDE modules?
>
> >>  - GCC visibility
> >
> >what does this mean for the buildtool ?
>
> Actually, this shouldn't be here. We need a configure test to check if gcc
> supports -fvisibility and, if so, enable the flag in CXXFLAGS.

Configure checks are a fundamental feature of cmake. It offers different ways 
to check for stuff. Just checking for the existence of files, try to compile 
stuff, try to execute stuff, grep files. 
E.g. the following line checks for a header and sets a variable accordingly:
CHECK_INCLUDE_FILES(dlfcn.h HAVE_DLFCN_H)

How to find out which CHECK_XXX() functions exist ? Just enter 
${CMAKE_ROOT_PATH}/Modules/ (usually /usr/local/share/CMake/Modules/) and 
check out the *.cmake files you'll find there. They all have descriptive 
names.

> >>  - automatic dependency resolution
> >
> >I'm not sure I understand exactly what you mean. If I say application
> > foo links to library libbar.so, cmake detects that libbar.so has to be
> > compiled before foo.
>
> That's it.
>
> Can it also do dependency resolution across different directories?
> (make/automake can't)

Inside one project (e.g. kdebase), yes.

> >>  - manual hints for dependency resolution
> >
> >Not sure. Can you explain more ? It is possible to manually add
> > dependencies of files.
>
> Like in make:
>
> foo.cpp: fooui.ui

Yes. (but for ui files this is not required, it works).

> >>  - flex/bison
> >
> >needs a custom macro similar to the ones for uic, moc, kconfig_compiler
> > etc.
>
> flex and bison are pretty standard... They should be supported
> out-of-the-box.

I was also a bit surprised that cmake doesn't come with ready-built flex/bison 
support. Since I have never used flex/bison myself until now please tell me 
what has to be done with these files so I can provide a sample 
implementation.
It's always the same schema: define a list of source files for your 
application:

SET(mySources main.cpp foo.cppl)

then call a macro which adds the generated files to these sources:

KDE_ADD_DCOP_SKELS(mySources blub.skel blah.skel)

which will create all necessary rules and dependencies for generating the 
appropriate files and add them to the list "mySources".
And finally create something from these files:

ADD_EXECUTABLE(myApp ${mySources} )

The macro implementation itself looks a bit hard to read on the first view, 
also due to the all-upper-case characters. Once you get around this, it's not 
hard. And, *all* cmake commands are documented on *one* manpage: 
http://www.cmake.org/HTML/Documentation.html . 

The macro implementation looks like this:

#now comes a macro
MACRO(KDE_ADD_DCOP_SKELS _sources)
   #iterate through all unnamed arguments, i.e. the ones coming after _sources
   FOREACH (_current_FILE ${ARGN})
      #get the filename without extension
      GET_FILENAME_COMPONENT(_basename ${_current_FILE} NAME_WE)
      #create the complete names for the generated files
      SET(_skel ${CMAKE_CURRENT_BINARY_DIR}/${_basename}_skel.cpp)
      SET(_kidl ${CMAKE_CURRENT_BINARY_DIR}/${_basename}.kidl)

      #add the two necessary commands for the dcop idl stuff
      #here you specify which file is created by this command,
      #the actual command and its arguments to run
      #and on which files the generated file depends
      ADD_CUSTOM_COMMAND(OUTPUT ${_kidl}
         COMMAND ${DCOPIDL}         
         ARGS ${CMAKE_CURRENT_SOURCE_DIR}/${_current_FILE} > ${_kidl}
         DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_current_FILE}
      )

       ADD_CUSTOM_COMMAND(OUTPUT ${_skel}
         COMMAND ${DCOPIDL2CPP}
         ARGS --c++-suffix cpp --no-signals --no-stub ${_kidl}
         DEPENDS ${_kidl}
      )
      #this one adds the generated file to the given list of source files
      SET(${_sources} ${${_sources}} ${_skel})
   #end of the loop
   ENDFOREACH (_current_FILE)
#end of the macro
ENDMACRO(KDE_ADD_DCOP_SKELS)

> >>  - kdeinit support (?)
> >
> >yes
>
> With a macro, right?

Of course. All custom functionality gets implemented via macros.
(I know the word "macro" has a negative touch for C++ people... [but even Qt 
uses macros for its signals and slots ;-) ] )

> >>  - pkg-config support
> >
> >If you want to use pkg-config with cmake, you are free to do so. But it
> > can also be done without pkg-config.
>
> The point here is: the tool should be able to read .pc files itself,
> without relying on running pkg-config and parsing the output. It should
> be easy to write tests for those.

I think this wouldn't be portable. Do they also exist on Mac OS X and 
Windows ? 
Directly reading pc-file is currently not implemented, but is possible if 
somebody does it.
The "native" cmake way of checking for existing stuff is to write 
FindXXX.cmake files for each package. A lot of them come with cmake.

> >>  - support rpath sanely
> >
> >cmake supports rpath. I don't know what exactly you mean with "sanely".
>
> This was one addition of mine.
>
> Currently, libtool will add to rpath everything you throw at it. That
> means /usr on some systems, making it impossible to build and/or run KDE
> when another KDE is already installed on prefix=/usr.
>
> We should be able to sanely control what goes on rpath.
>
> I know this is vague.

I'm afraid somebody else should check the behaviour of cmake in this regard.

> >Well, does it count that cmake can generate kdevelop project files ?
>
> This is one of the "musts":
>
> the file describing the build must be machine-parseable. That rules out
> Sconscript files directly, but it does not rule out scons.
>
> In my opinion, a simple "name = value" list should suffice: easy to
> understand, and easy to parse.
>
> I would even go so far as to say: keep the Makefile.am files!

About an easy syntax, e.g. kdevelop/parts/abbrev/CMakeLists.txt:

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

#create a kpart:
KDE_ADD_KPART(kdevabbrev abbrevpart.cpp abbrevconfigwidget.cpp 
addtemplatedlg.cpp abbrevconfigwidgetbase.ui addtemplatedlgbase.ui )

#link it to some kde libs
TARGET_LINK_LIBRARIES(kdevabbrev ${KDEV_PART_LIBS})

#install rules, relative to CMAKE_INSTALL_PREFIX
INSTALL_TARGETS(/lib/kde3 kdevabbrev)

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

KDE_ADD_KPART() comes from the newly created kdevelop/cmake/KDEMagic.cmake

> >>  - ability to build from svn:/trunk/KDE
> >
> >Don't know.
>
> Also one of my ideas.

http://www.cmake.org/Wiki/CMake_Scripting_Of_CTest shows an example how to use 
ctest with cvs. It seems as the cvs commands could simply be replaced with 
svn commands. Might be worth trying.

> Suppose you went into your local checkout of /trunk/KDE, where you have
> kdelibs, kdebase and kdepim. Instead of running:
>
> for dir in kdelibs kdebase kdepim; do
>   cd $dir; build-command; cd ..
> done
>
> I want to be able to do:
> build-command
>
> provided the necessary files are present in /trunk/KDE or, even better,
> automatically guessed.

It would probably need at least an CMakeLists.txt file in this directory, 
featuring something like this:

FILE(GLOB_RECURSE allDirs "/*/CMakeLists.txt") 
SUBDIRS(${allDirs})

(didn't test, just a quick guess from the man page).

> >> support for something like "make install DESTDIR=/tmp/kde-buildroot"
> >> to keep packagers happy
> >
> >I.e. changing the install path after compilation ? You can change the
> >CMAKE_INSTALL_PREFIX and then it will be installed there.
>
> This is not a "nice to have". It's a must-have feature.

Since the "install" target depends optionally on the "all" target, I see no 
reason why it shouldn't work.

...
> If you created FreeBSD binaries, you can't run them in Linux.
>
> If the tool helped with this, it would have to detect that (say)
> kconfig_compiler is used, and must, therefore, be compiled twice: once
> for the native tools, and once for the cross-compilation.

Sounds complicated.

> >Additional features of cmake:
> >-no other tools (no shell, no perl, no m4, no python, no automake, no
> > libtool, no autoconf, no autoheader, no aclocal,...)
>
> no make?

If you're on Mac and use XCode, then, yes, no make. If you're on unix and want 
use make, then you need make ;-)

> >cvs -d :pserver:anonymous at www.cmake.org:/cvsroot/CMake login
> > (respond with password cmake)
>
> Eww, cvs. That's so... March :-)

LOL
I guess this should become the quote of the week :-)

In some way cmake reminds me on Qt: it's written and maintained by a company, 
it's available as open source, it has good documentation, and it's 
implemented in C++.

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