Build system for KDE4

[Thiago Macieira]

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.

>>  - 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)

>>  - 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

>>  - 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.

>>  - kdeinit support (?)
>
>yes

With a macro, right?

>>  - --compile-slots, like in unsermake
>
>what's this ?

This is an unsermake feature: it allows the user to tell the tool how many 
simultaneous compilations it can launch. It is different from make's -j 
parameter in that it does not launch non-compilation jobs in parallel.

It is an important feature for those building in clusters and compile 
farms. I can launch 6 simultaneous compilations, but I don't want the 
linker running 6 instances on my machine.

Needless to say that any tool that simply generates Makefiles and lets 
make do the job, automatically fails this point.

>>  - 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.

>>  - 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.

>>  - ability to link & run uninstalled binaries
>
>Not sure. At least it adds the rpath. As I said, I'm no linking expert.

Here's something nice about libtool:

when you make an application, which depends on a library you're also 
building, you cannot run that application yet. If you did so, the dynamic 
linker would complain that it had not found the library.

libtool solves that by relinking your app with the library, and adding the 
path where the library is now (uninstalled) to rpath.

I must add, though, that some, if not most, KDE applications won't run 
even then. kdeinit apps, for instance, will try and load the kdeinit 
module. Other apps may fail due to missing xmlgui configs, or even 
missing icons.

>>  - easily integrated into KDevelop
>
>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!

>>  - ability to build from svn:/trunk/KDE
>
>Don't know.

Also one of my ideas.

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.

>> 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.

>It is possible to use cmake for cross-compiling. I do this every day but
> in a quite special setting (http://www.neundorf.net/cmake/). I also did
> some cross-compiling for Linux with cmake. But I can't tell how easy it
> would be to apply this to a KDE build system.

I've tried, and it's not easy. I did some Linux-to-FreeBSD cross-compiling 
a few years ago of the KDE code. The main reason that makes it difficult 
is that we create tools and then run them in the same build. (mcopidl, 
dcopidl, kconfig_compiler, etc.)

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.

>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?

>2) libtool convenience libraries
>They are not really supported by cmake. I don't know if they are
> actually required for anything. There are the following
> solutions/workarounds: -add support for conv. libs to cmake
>-write some clever macro which works good enough for us
>-an extension to cmake which allows to retrieve the object files
> contained in a static library and link to them

We use them, but they are not really an inconvenient.

The build system can simply forget about the "library" part of 
"convenience libraries". All it has to do is add the object files that 
compose the library into the final shared object.

On Linux and GNU ld systems, libtool uses --whole-archive. On systems that 
don't support that, it simply adds the *.o to the link list.

>cvs -d :pserver:anonymous at www.cmake.org:/cvsroot/CMake login
> (respond with password cmake)

Eww, cvs. That's so... March :-)
j/k

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

4. And æfter se scieppend ingelogode, he wrát "cenn", ac eala! se 
rihtendgesamnung andswarode "cenn: ne wát hú cennan 'eall'. Ástynt."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050614/448225fa/attachment.sig>