Build system for KDE4

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

-- 
Ralf Habacker