[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Build system for KDE4
From:       Chris Lee <clee () kde ! org>
Date:       2005-06-14 7:38:39
Message-ID: 20050614073839.GG9893 () parish ! picid ! com
[Download RAW message or body]

On Tue, Jun 14, 2005 at 10:40:15AM +0400, Vladimir Prus wrote:
> 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.

Neat. Haven't played with that (or even heard of it for that
matter.)

> > Must support:
> >  - generating binaries (duh)
> >  - generating shared libs (on all ELF platforms + MacOS X; Windows?)
> 
> Yea, including OSX and Windows.

Well, that's a good start. :)

> >  - icon installation
> 
> Not sure. If this just entails copying icons to some install-prefix-relative
> location, then there are no problems.

Shouldn't be too much more complicated. The rules are a little
weird in certain situations, but it shouldn't be too difficult to
add to any build system. It's just one of those simple things
that we obviously will need support for.

> >  - uic, moc, KConfigXT, etc
> 
> uic and moc are already supported. KConfigXT can be easily added.

That's a good start.

> >  - GCC visibility
> 
> Not sure this is build system issue.

Eh, I'm not either; it was mentioned in the discussion so I
included it in the notes.

> >  - automatic dependency resolution
> 
> Boost.Build has a global dependencies list (across all directories), and
> there were no dependency issues.

Right, that's good.

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

Also good, but in certain cases we might need to specify
something that the build system doesn't automatically pick up.
A fallback is necessary in those cases.

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

Basically, it means that you don't spawn a sub-process for each
subdirectory you enter. See the paper at:
http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html

> >  - --enable-final
> 
> What's this?

KDE builds support a configure option called '--enable-final'
which concatenates all .cpp files (in one dir) into one
foo_all.cpp file and compiles that instead of compiling each .cpp
file on its own. It used to provide a significant compile-time
speedup (not sure if it still does); it's not complicated to
support, and it's a useful feature to make sure that we're doing
header guards properly. Since we've supported it since ... well,
forever, as far as I know, it's something we need in a replacement
build system.

--enable-final is more useful for packagers than developers,
usually.

(Also, we provide a 'make final' target in the subdirectories
which does the equivalent of '--enable-final' but for each
subdirectory. This would also be really useful, although I can't
say it's an absolute must-have.)

> >  - builddir != srcdir
> 
> Yes.

Good.

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

Oh, boy. See http://www.suse.de/~bastian/Export/linking.txt -
basically, kdeinit is a workaround for the fact that on most UNIX
systems, the C++ compiler and the linker have sucked really badly
for a long time, so loading a C++ program would require lots of
redundant relocations as it figures out where all of the
functions are mapped in the libs. kdeinit loads a whole bunch of
KDE libs into RAM, and then forks KDE apps from them, which saves
lots of relocations and makes app start times really fast.

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

Yeah. Basically, we want to be able to compile libbar while foo
is linking. Not hard, but auto* gets it wrong.

> >  - pkg-config support
> 
> Not supported, but should be possible.

We'll need that. Lots of the other things we depend on have been
moving to pkg-config; even the X server is going that way soon.

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

Good, good.

> >  - easily integrated into KDevelop
> 
> Good question. I intent to try this.

Well, this just means basically that we need a fairly limited,
well-defined syntax for the build system instructions. Something
like scons is a little hairier than something with a well-defined
format that the KDevelop devs can build a separate parser for.

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

Yeah, shouldn't be hard as long as the build system is somewhat
extensible and not completely static.

> Another thing worth mentioned is already working support for DocBook (HTML
> and PDF generation).

That was something overlooked, good to know.

> On the downsides, Boost.Build does not have any support for config checks, 
> but I believe I can add them.

That would be very helpful.

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

Well, if worst comes to worst, we may just continue along the
path of unsermake and replace whatever other parts we need to.
It'd be much cooler if some $BUILD_SYSTEM_TEAM wanted to write
the perfect KDE build system for us instead.
[prev in list] [next in list] [prev in thread] [next in thread]