PROPOSAL: Use Cmake as the build system for Samba

[tridge at samba.org]

Hi Simo,

Thanks for looking into this (and thanks also to gd and andreas).

I have a few questions that aren't answered on the wiki page. 

First off, the build farm. Would we require cmake to be installed on
all build farm systems? 

This bit of your mail implies yes:

 > The first step we identified would be to ask our build farms to install
 > cmake on their systems and provide binaries if necessary. And then run
 > some basic build tests over build farm machines so that we can verify
 > the cmake transition on all hosts we care about while going through it.

but I don't think that will work well. Asking all our build farm
maintainers to install cmake will produce a mixed result. Some will do
it, and some won't. We'd lose some of the build farm systems.

What about making a 'cmake' project on samba.org, which is a copy of
the latest stable cmake source. Then we'd modify the build farm to
check for cmake (making sure it is the required version if installed)
and if needed build cmake and install it in a $BUILDFARM/cmake
directory inside the build farm area.

One flaw with this is that building cmake requires C++, so we may find
it doesn't build on some of our build farm systems due to lack of C++
or the usual C++ compiler problems. We'd need to try this and see what
happens and see how many build farm systems we'd lose.

Next, what happens to all of our ./configure options? We need some
equivalent for all (or maybe just most?) of the existing options. How
is that done with cmake?

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.

 > One of the most interesting things about Cmake, is that for the initial
 > steps it can be developed in a completely parallel way to the current
 > build system, so that the transition should not cause extended building
 > problems while it is carried over.

This is very important. We're doing very rapid development right now,
both in s3 and s4. While improving the build system is important, it's
not important enough for us to stall development for a long period
(ie. more than a day or two).

Who would do the conversion of all of the .mk and .m4 files over to
cmake? That will be quite a lot of work I think.

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

Cheers, Tridge