Build system for KDE4
thiago at kde.org
Tue Jun 14 05:26:17 BST 2005
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.
Can it also do dependency resolution across different directories?
>> - manual hints for dependency resolution
>Not sure. Can you explain more ? It is possible to manually add
> dependencies of files.
Like in make:
>> - flex/bison
>needs a custom macro similar to the ones for uic, moc, kconfig_compiler
flex and bison are pretty standard... They should be supported
>> - kdeinit support (?)
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
>> - 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
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 ..
I want to be able to do:
provided the necessary files are present in /trunk/KDE or, even better,
>> 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,...)
>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 :-)
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel