PROPOSAL: Use Cmake as the build system for Samba

[Andreas Schneider]

On Wednesday 17 February 2010 22:40:24 tridge at samba.org wrote:
> Hi Simo,

Hi Tridge,
 
> 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?

Yes, cmake and make are required to be installed. CMake generates Makefiles, 
these Makefiles make use of cmake for a lot of stuff again.

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

Is it really such a big problem? It would be possible to bootstrap it on the 
system or install binaries.

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

I think this would be doable. Put a binary there or bootstrap it on the 
system.

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

According to their Dashboard they built it on all systems which are available 
in the buildfarm except one (True64). I've found reports that it bootstraps on 
True64. Maybe we can do a nightly build on this machine. I'm sure they will 
fix bugs for this platform.

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

CMake supports options. I don't see a problem here. CMake provides a ncurses 
and a Qt frontend which lists all options with descriptions that can be 
changed.

> 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've talked with Jelmer about CMake at FOSDEM. We haven't discussed this in 
detail and I'm interested in his feedback too.

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

I would start to write what can be called the infrastructure to get started. 
Simo and Günther will help with the migration. The plan is to work in a 
separate repository so that we don't break anything or distract other 
developers.

It will not make sense to start if people don't consider to switch to CMake or 
most of the developers are against it :)
 
> 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).

Some time ago I migrated WengoPhone (QuteCom now) to CMake. They used scons 
and they had some real trouble building it on different systems. 64bit support 
was easy to implement and it was really slow. At the same time KDE decided to 
use CMake instead of SCons. See

http://lwn.net/Articles/188693/

In the meantime a lot of changed and more and more projects switch to CMake.


	-- andreas