CMake Proposal

tridge at tridge at
Wed Feb 24 17:40:19 MST 2010

Hi Simo,

 > To be honest I would trade being "special" with being "more standard"
 > every day, and I hoped that working on the build system would help us do
 > just that.

I think the degree of 'specialness' we need for cmake or waf is the
same. The 'special' stuff is things like putting in once place the
rule for converting 1 IDL file into 7 output files. I've called that
the SAMBA_PIDL() rule. In cmake you'd have to have much the same sort
of rule, unless you want to have the syntax for running pidl spread
across dozens of places.

Most of the stuff I've put in is in this category, and you
would need equivalents if you try to convert all of Samba to cmake. 

I've tried to encourage Andreas to take this approach for his cmake
effort. The current approach that has been taken with the cmake rules
for libreplace and tevent are not scalable. If you converted all of
Samba along those lines then you'd end up with tens of thousands of
lines of cmake rules. If we then decide to change our approach we'd
have to change it everywhere. That would create a maintainence

I also think calling cmake 'standard' is a bit of a stretch. The
"standard" in the FOSS world is autotools, which is used by the
overwhelming majority of FOSS packages. I'd really like our build
system to be as similar in usage to our existing autotools build
system as possible. That means things like

  configure --enable-debug --prefix=/some/path

in waf we get:

  waf configure --enable-debug --prefix=/some/path

which is not much extra to learn. We could even have a one line
configure script that just calls waf with the same arguments.

For some reason the cmake developers decided not to go with this
'standard' syntax, and instead invented their own. The same goes for
the cmake language - they invented their own instead of using an
existing language. 

So telling me that going with cmake gets us "standard" is really not
very accurate. If we wanted 'standard' then we'd use
autoconf/automake/libtool, but as we don't want to do that, let's at
least make it not a difficult task to learn to use the new system if
you know the old one.

Similarly, I'd like our config system to also be familiar to people
who already know autotools. So for example in autoconf we have:

  AC_CHECK_HEADERS(stdbool.h stdint.h sys/select.h)

with waf in Samba the equivalent is:

  conf.CHECK_HEADERS('stdbool.h stdint.h sys/select.h')

using cmake we have:

  check_include_file(stdbool.h HAVE_STDBOOL_H)
  check_include_file(stdint.h  HAVE_STDINT_H)
  check_include_file(sys/select.h HAVE_SYS_SELCT_H)

The cmake approach is more verbose, and is more susceptible to typos
(as the define is not automatic). Maybe a macro could be used in cmake
to make it more familar to people used to autoconf?

Cheers, Tridge

More information about the samba-technical mailing list