PROPOSAL: Use Cmake as the build system for Samba

[Andreas Schneider]

On Thursday 18 February 2010 17:15:07 Jelmer Vernooij wrote:
> Hi Simo, Tridge, Andreas,

Hi Jelmer,

> CMake uses timestamps to see if files that depend on changed files need
> to be rebuilt. This severely reduces the usefulness of automatic
> dependencies when generated header files are being used. For example,
> changing a core C file in Samba (even if no signatures are changed) will
> trigger a rebuild of the prototype header file for that C file, and that
> header being touched will cause a recompilation of all files that
> include it, etc.

that's true, but I think people would complain if this is not done and you 
changed something important.

If you're using the the Unix Makefile generator, 'make ${target}/fast' will 
build the target without any dependency checks. This is *only* for developers, 
who *know* what they are doing!

> We'd have to switch both Samba 3 and Samba 4 at the same time, or move
> away from the merged build. I'd like to see the CMake migration done in
> a separate branch that is then merged into mainline Samba the moment we
> switch.

I would prefer to start with Samba3 or Samba4. Then the next Samba source and 
do the merged build in the end. Well the merged build should always be kept in 
mind so that we don't have to rewrite everything in the end.
 
> CMake supports handling custom compilers such as pidl; does it allow for
> pidl to take multiple input files and generate multiple output files?

Yes, it does. A look at 'man cmake' and search for add_custom_command. You 
specify the output files, so that it knows about dependencies.

> If we find issues with the compiler support in CMake, can we work around
> that in the cmake files locally or do we have to get the fix upstream
> and tell users to install a version of CMake from their version control
> system ?

Compiler support is normally defined in the platform files. Take a look at
/usr/share/cmake/Modules/Platform/Linux.cmake for example. You can copy this 
file to the module directory in your source and change stuff.

> Can we create arbitrary makefile targets, e.g. to support the current
> test infrastructure?

Yes, see add_custom_target in the manpage.
 
> Does it support multi-architecture compilations? When cross-compiling we
> need to build some of the compilers (asn1c, compile_et) for the build
> platform and target platform and most other things just for the target
> platform.

Yes, cross compilation support has been added in CMake 2.6. All you have to do 
is to write a toolchain file which defines the compilers and paths.

I've cross-compiled Windows binaries for libssh on Linux with MinGW.

> 
> Out of source builds are possible - are in-source builds also still
> possible?

Yes, it is possible but normally I add code which aborts the build if you do 
that and describes what you should do.
 
> While we don't require a custom build system, it looks like we need
> quite a bit more "support code" than with plain autoconf for projects
> like talloc or tevent. E.g.:
> 
> lib/talloc% wc -l *.m4 **.mk
>  192 total
> 
> lib/talloc% wc -l CMakeLists.txt *.cmake cmake/Modules/*
>  827 total

There are some files in there which aren't used or needed and they should be 
removed. There are even files in there from libreplace. I think we have to 
write a bit more support code for ancient systems.

I've written e.g. CheckSignalType.cmake and CheckSignalType.cmake.in for 
libreplace which has been copied to the talloc tree.

Later I've found out that it can be removed. Samba requires C99 and the signal 
type in C99 is always 'void'. Check build.samba.org, it is always void. I 
think I should create a patch for that.


Cheers,

	-- andreas