PROPOSAL: Use Cmake as the build system for Samba

simo idra at
Thu Feb 18 06:39:01 MST 2010

On Thu, 2010-02-18 at 17:44 +1100, tridge at wrote:
> Hi Simo,
> I had an interesting discussion with Brad Hards today, who has some
> experience with the conversion of KDE to cmake.
> Brad's overall impression of cmake is very positive. It has worked
> very well for KDE.
> The interesting thing is that the problem I raised with cmake versions
> and fixes has happened with KDE, but for KDE it isn't a major
> problem. For Samba I think it might be a much bigger problem.
> Every now and again KDE switches version of cmake. Everyone who
> develops KDE then needs to build and install the new version of
> cmake. For KDE, that means just the developers, as end-users building
> their own version of KDE is extremely unusual (unless its via a system
> like the one in Gentoo). It is also basically unheard of for someone
> to try and build the current version of KDE for something like RHEL3.
> For Samba it's quite different. It isn't just the Samba developers who
> build and install Samba, it's also anyone who wants Samba on their
> system and their OS doesn't have the latest version. That means many
> of our end users will have to build and install the right version of
> cmake, and when we switch versions then they will also have to
> switch. It gets even harder when people have ancient Linux or Unix
> versions. Yes, cmake may build on Irix, but does it build on all the
> older versions of Irix? What about old versions of RHEL or SLES?

Well for sure anything based on a modern version of python will never
let you build Samba on old versions of RHEL.

RHEL3 has python 2.2
RHEL4 has python 2.3

Certainly rebuilding the whole of python is never going to fly. And at
the same time I am certain we are not going to have the time or
resources to keep something python-based to build on anything older than
a few years. And I am not even considering modules ...

Just recently we dumped support for python 2.3 compatibility in Samba 4
because it was broken anyway.

Rebuilding CMake *if necessary* seem orders of magnitude much easier, as
it is very well self contained as far as I can see.

> It also means we will have to not just get the build farm maintainers
> to install cmake once, but multiple times. Whenever we change versions
> we again have to ask all build farm maintainers to change version.
> We switched to generating configure files centrally on to
> avoid this type of build version dependency. It used to be a great
> pain when everyone had to have the right version of autoconf. I'd be
> pretty reluctant to go down that path again.

To be honest Tridge I really don't see it as this big of a deal, you are
not forced to move to a new version of CMake unless you need to use a
new feature or there is a critical bug that forces you to. As far as I
know newer versions of CMake build older files just fine.
As you say it is nothing that we haven't done or keep doing, but
certainly if I should judge on this criteria I'd definitely choose CMake
over python any day.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list