Build system for KDE4
ralf.habacker at freenet.de
Tue Jun 14 11:49:04 BST 2005
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 (?)
> - 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 ?
More information about the kde-core-devel