CMake Proposal

[tridge at samba.org]

Hi Bill,

 > Seems that at this point there are 3 issues with CMake on the list.

It is a bit more than that.

 > However, both 1 and 2, are not so difficult to address.  For 2, the 
 > following CMake code should do the trick:
 > 
 > include(CheckIncludeFile)
 > function(cmake_ac_check_headers)
 >    foreach(file ${ARGN})
 >      string(REPLACE "." "_"  have_var "${file}")
 >      string(TOUPPER "${have_var}" have_var)
 >      check_include_file("${file}" "HAVE_${have_var}")
 >    endforeach()
 > endfunction(cmake_ac_check_headers)

yes, I realise that it's possible to wrap things like this in
cmake. The point I was trying to make to Andreas was that the approach
he had taken in building the cmake rules for tevent and talloc was not
a good approach. He'd decided to go with 'raw' cmake rules, which
makes the resulting cmake rule files both overly verbose and error
prone.

So if someone does want to keep pursuing the cmake option then please
use wrapper functions what prevent simple mistakes. These wrapper
functions can then also emforce the 'project rules' to ensure we don't
end up in a complete mess again.

 > For 1, this has come up so many times, and is not really that hard to 
 > implement.  I can commit to getting this done in the master branch of 
 > CMake in the next month.   It most likely will not be in a release for 
 > another 6 months.  However, it is a bit of a cosmetic issue, as 
 > -Dfoo=bar or --foo=bar is really only different by one character.

This illustrates several of the problems I have with cmake.

 1) if we do need something changed, then it can take months to get
 something into a release, and it will take even longer (years?) for
 it to get into the major distros. That is why I like having the build
 tool small enough to ship with Samba. When I get a fix from the waf
 maintainer we can put it in Samba in minutes. 

 2) The cmake designers made a fundamental mistake in deciding to
 write their own embedded language (the 'cmake' language) instead of
 using an existing extensions language. Writing your own language is a
 lot of fun, but it is almost always the wrong thing to do. There are
 plenty of excellent langagues out there that are embeddable, popular
 ones these days include lua, python, perl, js (eg. ejs), ruby, java
 etc etc. 

 Real embedded languages don't require you to rebuild things in order
 to change the command line option handling. Language designers know
 that different people want to handle command line options in
 different ways, so they write a generic command line option handler,
 and then the applications that use it get to choose how to deploy it.

 By writing their own language, the cmake developers lumber themselves
 with the task of reinventing every wheel in the programming language
 world. The decision also leaves the users of cmake with no way of
 working around trivial problems in cmake.

 The --option problem isn't a large one, but what about when we hit a
 more significant one? With cmake we'd be stuck. I know that cmake has
 been around for a while, and maybe there weren't a lot of good
 embedded languages to choose from when cmake started, but why didn't
 the cmake developers notice the trend to use an existing embedded
 language and add one with interfaces for their internal APIs? We've
 done that for Samba, and it's done by lots and lots of apps. For a
 build system it's a pretty obvious thing to do!

 Writing your own language also means that your users have to learn a
 new language, but without the sorts of resources that are available
 online for mainstream languages. If I want to do something in lua,
 python, ruby etc, then I can usually find out how to do it in seconds
 with a google search, and I'm likely to even find a tutorial on the
 topic, and probably a bunch of modules implementing exactly what I
 want. When you invent a new langage, especially a domain specific
 one like the cmake langage, you lose all that.

 3) The affects of (2) are exaccerbated by the fact that the cmake
 designers decided to do things their own way rather than choosing
 the existing idioms that are widely known and are familiar to
 users. In the Unix/FOSS world, "configure --prefix=/blah
 --some-option=foo" is embedded in the psyche of administrators
 everywhere. To choose a different syntax is just silly.

 4) rather bizarrely, the cmake designers decided that even though
 they want to write their own programming language, they wouldn't
 write the thing that is most important to their project, which is a
 an actual build system. Instead it writes out a makefile, and relies
 on make. That means that cmake can't do anything during the build
 phase that make can't do. Make is not terrible, but it's not exactly
 state of the art! You end up with trivial problems like the fact that
 cmake can't show a progress bar for the progress of the build,
 because it doesn't know the progress of the build, because it isn't
 doing the build!

The other really big problem I have with the cmake proposal is that
the people proposing it don't seem to have taken the time to look at
our existing Samba build system to see what it is they are trying to
replace. The existing build system has problems, but is also has some
great features. You can't seriously expect to replace it without
understanding it first. That means diving into the config.mk files and
understanding what they are and how they work. It also means
understanding how it integrates with subunit testing, and how things
like 'make testenv' are implemented.

Yes, it's too complex, and yes, it's hard to maintain. Replacing it
would be a good thing, but whoever does the replacement must
understand the existing system or we'll end up losing really important
features. 

Cheers, Tridge