PROPOSAL: Use Cmake as the build system for Samba

[Jelmer Vernooij]

Hi Simo, Tridge, Andreas,

On Thu, 2010-02-18 at 08:40 +1100, tridge at samba.org wrote:
> I'd also very much like to hear what Jelmer thinks of cmake. Jelmer's
> build system for s4 is often criticised, but it does encapsulate a lot
> of very detailed module dependency information in a compact manner
> (the .mk files all over Samba4). I think it is quite impressive what
> Jelmer achieved with that, and I'd want to be sure we won't be losing
> key features if we went to cmake.
I'd rather not refer to the current build system as mine. I realize I
have ended up as the de facto maintainer because I have done most work
on it recently, but I've just worked with what was there to get it to do
what I needed for Debian and to support Python modules. I wasn't
responsible for the original design and while I have had to make some
changes to the design it's still completely different from how I would
design a build system if I were to design one from the grounds up. 

Switching to a different build system seems like a good idea to me, as
long as its strictly better than what we have at the moment. I don't
particularly like CMake but I agree it's at least better than what we
have now or the alternative of autoconf+automake+libtool. My main
concern is that somebody would have to put in the effort to convert
Samba 3 and Samba 4 to CMake and make sure CMake gets installed on the
build farm hosts, but from what I understand RedHat is willing to take
care of that?

CMake uses timestamps to see if files that depend on changed files need
to be rebuilt. This severely reduces the usefulness of automatic
dependencies when generated header files are being used. For example,
changing a core C file in Samba (even if no signatures are changed) will
trigger a rebuild of the prototype header file for that C file, and that
header being touched will cause a recompilation of all files that
include it, etc.

We'd have to switch both Samba 3 and Samba 4 at the same time, or move
away from the merged build. I'd like to see the CMake migration done in
a separate branch that is then merged into mainline Samba the moment we
switch.

CMake supports handling custom compilers such as pidl; does it allow for
pidl to take multiple input files and generate multiple output files?

If we find issues with the compiler support in CMake, can we work around
that in the cmake files locally or do we have to get the fix upstream
and tell users to install a version of CMake from their version control
system ?

Can we create arbitrary makefile targets, e.g. to support the current
test infrastructure?

Does it support multi-architecture compilations? When cross-compiling we
need to build some of the compilers (asn1c, compile_et) for the build
platform and target platform and most other things just for the target
platform.

Out of source builds are possible - are in-source builds also still
possible?

While we don't require a custom build system, it looks like we need
quite a bit more "support code" than with plain autoconf for projects
like talloc or tevent. E.g.:

lib/talloc% wc -l *.m4 **.mk
 192 total

lib/talloc% wc -l CMakeLists.txt *.cmake cmake/Modules/*
 827 total

> Finally, has anyone done a comparison of SCons versus cmake for use in
> Samba? If we're going to change build system again we should look into
> which one suits us best. The python extensibility of SCons certainly
> does appeal to me, as I'm concerned that we will hit something we
> currently do with the .mk/.m4 files that cmake can't do and we'll be
> stuck. With SCons my understanding is that we can extend the build
> system by adding fragments of python if needed. With cmake we can also
> extend, but we would need to do it in a new language (cmake has its
> own interpreter for the 'cmake' language builtin).
Last I checked scons (a couple of years ago now), it was quite a nice
system (I much prefer it over CMake) but horribly slow for something
like Samba. I worked on a fork of Samba that used scons back then and
gave up on it halfway through because of this.

scons uses checksums to see if files have changed rather than
timestamps, something that actually makes parallelism with generated
header files useful.

I haven't looked at scons recently so I have no idea whether the
performance issue has been addressed. There are some large users of it
these days so I guess it is at least less of a problem now (VMware,
Google Chrome, Blender, Ardour).

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100218/be909e57/attachment.pgp>