Build system for KDE4

[Ralf Habacker]

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

can anybody tell me what this means. I have search in kde-devel, but hadn't 
found any usefull, 


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

dito 
>  - multiple build targets (libfoo, libbar, libbaz) in one file
>  - --compile-slots, like in unsermake
probably --compile-jobs, which mean parallel make ? 

>  - pkg-config support
>  - support rpath sanely
what kind of behavior is '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
what includes this ability ? 

-- 
Ralf Habacker