Build system for KDE4
ghost at cs.msu.su
Tue Jun 14 07:40:15 BST 2005
Chris Lee wrote:
> 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.
I would like to bring Boost.Build V2 (http://boost.org/boost-build2) into
the discussion. I might be biased, being the primary developer, but I think
the following feature list is pretty much covered.
> Must support:
> - generating binaries (duh)
> - generating shared libs (on all ELF platforms + MacOS X; Windows?)
Yea, including OSX and Windows.
> - icon installation
Not sure. If this just entails copying icons to some install-prefix-relative
location, then there are no problems.
> - uic, moc, KConfigXT, etc
uic and moc are already supported. KConfigXT can be easily added.
> - GCC visibility
Not sure this is build system issue.
> - automatic dependency resolution
Boost.Build has a global dependencies list (across all directories), and
there were no dependency issues.
> - manual hints for dependency resolution
In another email it was said that something like:
is needed. So far, uic support works without manual dependencies.
> - flex/bison
> - non-recursive (flat) builds
Not sure what it means. One can build in any directory, and only targets in
that directory will be updated (together with all dependencies).
> - --enable-final
> - builddir != srcdir
> - simple to the point of being learnable within 5 minutes
It's subjective, but a minimal file in a directory can contains just:
lib whatever : whatever.cpp ;
> - kdeinit support (?)
> - multiple build targets (libfoo, libbar, libbaz) in one file
> - --compile-slots, like in unsermake
Is this "-j" that applies to compilations only? Yes, that's how -j works in
Boost.Build -- compilations are parallel, but linking is explicitly
> - pkg-config support
Not supported, but should be possible.
> - support rpath sanely
> - ability to link & run uninstalled binaries
I think this works. If you build, but don't install your project, you can
run all executables without problems, because paths to all libraries in the
project are added to rpath for the executable. On installations,
executables are relinked with rpath poiting to install locations (if
> - easily integrated into KDevelop
Good question. I intent to try this.
> - 'admin' needs to be shipped in KDE instead of in src of each app
> (if we keep the 'admin' dir, that is)
Should be doable. I'd expect that kde support will be just an single module
for Boost.Build, and placing it in any location where Boost.Build can find
it should be enough.
Another thing worth mentioned is already working support for DocBook (HTML
and PDF generation).
On the downsides, Boost.Build does not have any support for config checks,
but I believe I can add them.
I clearly understand that no build system can work for KDE right of the box,
and will require tuning and optimisation, but Boost.Build might be a good
basic. Comments are appreciated!
More information about the kde-core-devel