Build system for KDE4

[Vladimir Prus]

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:

   foo.cpp: fooui.ui

is needed. So far, uic support works without manual dependencies.

>  - flex/bison

Supported.

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

What's this?

>  - builddir != srcdir

Yes.

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

What's that?

>  - multiple build targets (libfoo, libbar, libbaz) in one file

Supported.

>  - --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
serialized.

>  - 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
necessary).

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

- Volodya