PROPOSAL: Use Cmake as the build system for Samba

[simo]

On Thu, 2010-02-18 at 08:40 +1100, tridge at samba.org wrote:
> 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? 

Yes, and there are a few ways to do that.

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

Yes, I considered that.

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

I didn't consider building cmake ourselves, I did instead consider
deploying an already built binary. Would there be any problem with
that ?

> 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'll let Andreas comment on that, but I assume we will have the same
range of options.

> 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 like Jelmer perspective too, I know Andreas and Jelmer had some
discussion on this at FOSDEM, and I'd like for them to further comment.

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

Yes this is one of the reasons I even considered this doable.

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

As I said Andreas is volunteering and I and Guenther will also lend a
hand where possible. We would be happy if anyone else, especially people
like Jelmer and Metze would also like to contribute.

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

I haven't done a comparison with SCons but the independence of cmake
from external interpreted languages is a feature I highly appreciate.

With python I see a problem, we already do not support anything less
than 2.4 and soon python 3.0 will start to appear upstream. 2.4 and 3.0
are not really compatible, so I think that adopting a build system that
depends on python might give us trouble on some platforms in time.

cmake is would avoid that.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>