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)