CMake Proposal

[Bill Hoffman]

tridge at samba.org wrote:
> Hi Bill,
> 
>  > Seems that at this point there are 3 issues with CMake on the list.
> 
> It is a bit more than that.
> 
OK, good to have the real issues on the list.

> 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.
> 
I agree, the project should be done with care, and I am willing to help 
whoever does the CMake implementation to make sure it is as good as 
possible.

>  > 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. 
> 
We provide binaries for all platforms that work without a root install. 
  This really was not that much of a problem for KDE.  I think CMake 
should be able to do what you need today without binary changes.
>  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. 
> 
It was not for "fun".  The idea was to only depend on the C++ compiler. 
  When building a C++ project you have to have one of those.  You don't 
have to have python, lua, or some other language.  However, there is one 
danger of a using a "real" language, people will want to use it.   Each 
project will have serious customization and will not be able to share 
common features. The build rules fro a project will be a program 
customized deeply for each project.

>  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.
It has custom build rules and the standard rules.  You can add compilers 
and run command without modifying the CMake core.   We did explore lua 
at one point, and although a different syntax, it basically ended up 
with the same thing.   add_executable( some args) is add_executable(some 
args) in just about any language.  If you want to change the core c++ 
from the language that is a whole different thing to do.  Anyway, even 
if we did choose a new language (which we won't be doing any time soon), 
it would not really help you pick CMake as it would obviously take a 
long time to do.

So, the question is, can CMake do what you need it to do today. I 
believe the answer to that is yes.

> 
>  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.
The design choice was actually to use a gui (cmake-gui and ccmake) to 
choose the configuration options.   The choice of -D was closer to what 
you would give a compiler, than a command line program.   Anyway, most 
likely it was a mistake not to implement this a while ago, but I still 
think it is a cosmetic thing.  We spent more time making sure we tested 
CMake well, and covered more platforms, and had more core build features.

> 
>  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!
> 
CMake allows the developers of a project to use the tools they are most 
familiar with.   In the linux/unix world that is make and the command 
line.  At some point we will most likely create a new command line build 
tool as well.  However, in the windows world we generate visual studio 
IDE project files, and on the Mac Xcode project files.  This allows for 
developers to use the tools they like to use.  If you force a Windows 
developer to use a command line build tool like waf, they will be 
unhappy, they never use the command line.   Some Mac developers are the 
same with Xcode.  So, writing our own build tool would have taken away 
from other features at some point.

> 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.
> 
I will let others comment on this part, as I have not looked at it at 
all.   However, I think the proposal was to spend some serious time 
implementing the new build system.

-Bill