Build system for KDE4

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

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska / Kexi Team
  http://www.openoffice.com.pl  |  http://www.kexi-project.org
  KDElibs/Windows: http://wiki.kde.org/tiki-index.php?page=KDElibs+for+win32