Build system for KDE4

[Ralf Habacker]

Am Montag, 13. Juni 2005 23:10 schrieb Ralf Habacker:
> Am Montag, 13. Juni 2005 15:00 schrieb Jaroslaw Staniek:
> > Ralf Habacker said the following, On 2005-06-13 08:24:
> > 
> > > Am Montag, 13. Juni 2005 06:25 schrieb Chris Lee:
> > > 
> > >>We had a discussion in #kde-devel earlier about what KDE's
> > >>requirements for a build system are. What are the current
> > >>problems we have with autoconf/automake/libtool? What features do
> > >>they provide that we really care about? How hard would it be to
> > >>replace any/all of them with things that suck less?
> > >>
> > >>I took notes of the discussion. They're below; I'd like to get
> > >>more feedback on this.
> > >>
> > >>(One of the first points that I'm sure someone will make is
> > >>"auto* is cross-platform! We need to support KDE on platforms
> > >>that aren't Linux!" etc. Look, we realize this. However, auto*
> > >>provides lots of problems for us on platforms we do care about,
> > >>including MacOS X and Windows. (Ask RangerRick or js about them
> > >>on IRC, or email them.)
> > >>
> > >>Just because we're using auto* and friends doesn't mean that our
> > >>code works; as a matter of fact, RangerRick noted that so far,
> > >>all of his issues with the Mac port of the work-in-progress KDE4
> > >>have been build issues, and none of them have been code-related yet.
> > >>
> > >>This is clearly a problem and since KDE4 is an aggressive new
> > >>major release, we should solve it in the KDE4 timeframe. We don't
> > >>want to have to wait until KDE5 for a build system that doesn't
> > >>suck, do we?
> > >>
> > >>Without further ado, the notes from the discussion.
> > >>
> > >>Must support:
> > >> - generating binaries (duh)
> > >> - generating shared libs (on all ELF platforms + MacOS X; Windows?)
> > >> - icon installation
> > >> - uic, moc, KConfigXT, etc
> > >> - GCC visibility
> > >> - automatic dependency resolution
> > >> - manual hints for dependency resolution
> > >> - flex/bison
> > >> - non-recursive (flat) builds
> > >> - --enable-final
> > >> - builddir != srcdir
> > >> - simple to the point of being learnable within 5 minutes
> > >> - kdeinit support (?)
> > >> - multiple build targets (libfoo, libbar, libbaz) in one file
> > >> - --compile-slots, like in unsermake
> > >> - pkg-config support
> > >> - support rpath sanely
> > >> - ability to link & run uninstalled binaries
> > >> - easily integrated into KDevelop
> > >> - 'admin' needs to be shipped in KDE instead of in src of each app
> > >>   (if we keep the 'admin' dir, that is)
> > >>
> > >>Would be nice, but not necessary:
> > >> - having a standard and distributed build system and test suite
> > >> - ability to build from svn:/trunk/KDE
> > >>
> > >>Thoughts?
> > > 
> > > 
> > > kde is based on QT. QT have qmake, which already supports many 
platforms. 
> > > There are some extensions required, but as far as I know qmake, there 
are 
> > > many things already solved. 
> > > Because the autotools are not working very good on native windows 
Jaruslav 
> > > Staniek already uses qmake for compiling kde. 
> > 
> > Yeah, anyway I am not qmake fan (take a look at kdelibs/win/tools/ to see 
> what 
> > dirty fixes are performed). SCons would be my favourite. Among others, 
> there's 
> > one more advantage: with python scripts I wont run off with win32 PIDs on 
> > cygwin. For now oferflowing PIDs counter forces me to (sic!) reboot. For 
me, 
> > to go with SCons we may need somebody who is less absorbed by actual 
> > development but wants to help and is able to hack both on unix and win32, 
> and 
> > test, test, test, test....
> 
> What about a wiki page on kde.org with a feature and required efforts map of 
> the mainly discussed build system. This may help to give a better overview 
of 
> the procs and cons ? 
> 
Here ist it: 
http://wiki.kde.org/tiki-index.php?page=KDE+4+Build+Systems+Feature+Map. 
Everybody welcome to add content. 

Ralf Habacker