From kde-core-devel Mon Jun 13 06:24:00 2005 From: Ralf Habacker Date: Mon, 13 Jun 2005 06:24:00 +0000 To: kde-core-devel Subject: Re: Build system for KDE4 Message-Id: <200506130824.11524.ralf.habacker () freenet ! de> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111864379926978 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. > - generating binaries (duh) qmake:yes > - generating shared libs (on all ELF platforms + MacOS X; Windows?) qmake:yes > - icon installation qmake:yes > - uic, moc, qmake:yes > KConfigXT, etc qmake:unknown > - GCC visibility ? > - automatic dependency resolution qmake:yes > - manual hints for dependency resolution ? > - flex/bison qmake:yes > - non-recursive (flat) builds qmake:yes > - --enable-final qmake:probably no > - builddir != srcdir qmake:yes > - simple to the point of being learnable within 5 minutes qmake:yes > - kdeinit support (?) qmake:no (yet,has to be implemented) > - multiple build targets (libfoo, libbar, libbaz) in one file qmake: no (yet,has to be implemented) > - --compile-slots, like in unsermake qmake: yes uses make > - pkg-config support qmake: yes > - support rpath sanely qmake: yes > - ability to link & run uninstalled binaries qmake: yes (using libtool) > - easily integrated into KDevelop qmake:yes > - '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 May be good to have a feature/tool/todo matrix to get an overview. Regards -- Ralf Habacker