Build system for KDE4

[Dave Feustel]

On Sunday 12 June 2005 11:25 pm, Chris Lee wrote:
> 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!" 


How about OpenBSD? :-)

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