PROPOSAL: Use Cmake as the build system for Samba

tridge at tridge at
Thu Feb 18 15:42:07 MST 2010

Hi Björn,

 > a word about the commercial UNIXes: I think most of them are located in
 > Göttingen actually.

I assume you mean the ones in the build farm. If you mean that all use
of commercial UNIXes has moved to Göttingen, then I guessed I must
have missed that in the news :-)

 > I'll take care that cmake will find its way there.

We can probably solve the build farm problem by putting cmake as a
project in the build farm, and auto-building it if needed, then making
it available much like we do for smbtorture4. It does mean relying on
C++, and I don't know how much of a pain that will be, but that isn't
my primary concern.

My primary concern is all of the users who download and build Samba
themselves. Unlike projects like KDE, we have a significant number of
end users who build Samba. I am trying to point out that we will be
causing those users some extra pain. In some cases it will be a small
amount of pain, in some cases it could be a lot.

If a python based build system can't do what we need to do
(ie. produce a easy to maintain build system that can handle all of
the complexities of what we do now), and if cmake can do that, then
I'd certainly support using cmake. I just want us to consider
alternatives that don't involve us putting our users through any
additional dependency pain.

So can we get back to comparing the technical merits of the systems? I
know cmake is probably more popular than SCons/waf, but if popularity
were the key factor then we'd be choosing VisualC on Windows. So what
exactly are the technical advantages of cmake over waf? Can it handle
the build requirements of Samba (especially things like the merged
build!) in a better/neater way?

Cheers, Tridge

More information about the samba-technical mailing list