PROPOSAL: Use Cmake as the build system for Samba

[tridge at samba.org]

Hi Simo,

One of my biggest concerns with cmake is that it's a big C++ prog
(it's 350k lines of code).  I know it's got good support behind it,
but if we find a bug, or a limitation that we want to work around,
then we could be stuck.

This is because if there is some bug fix needed in cmake itself, then
suddenly everyone (all people who build samba, all build farm machines
etc) will need to be running a patched version of cmake. That means
lots of pain for lots of people.

This is where a python based build system has a huge advantage. If we
find a bug in waf/SCons and it needs a fix then we can just include
the new version with Samba, as build/waf or build/SCons. It's a tiny
script, small enough to put in our source tree without us thinking
twice about it (it's just one file). We can't just throw cmake into
our source tree without major headaches.

So if cmake and a python alternative are close in other ways, then for
me the python alternative would win just based on this advantage. 

It may be that we find that waf/SCons don't meet our needs in some
way, and if they don't then cmake may well be the right choice, but I
think we should at least try and see if we can avoid this problem by
using a python based build system and see if it meets our needs.

I've just had a quick look at waf, and so far it's pretty impressive:

  - a book is available here:
    http://freehackers.org/~tnagy/wafbook/ch01.html

  - it supports configure like syntax:
      waf configure --prefix=/some/prefix --destdir=/some/dest/dir

  - it separates the configure and build phases, like we do now

  - it has a nice -p progress option (as tytso discovered with e2fsck,
    a progress bar makes things feel faster!)

  - it is designed to be included in projects, as opposed to being
    installed on the system. The developers actively discourage you
    from installing waf, and instead encourage you to add the 89k
    script to your source tree. That's ideal for Samba, though it's
    less ideal for things like talloc, tdb, ldb etc where 89k is a
    bigger proportion of the system. Probably not a showstopper
    though.

What I don't know is how well it handles RPATH tricks for running
uninstalled binaries (I really don't want to get into libtool and
.libs script hacks). I also don't know how well it supports the
re-linking needed when installing, and whether this will work with the
Debian rules on such things.

Cheers, Tridge