CMake Proposal
tridge at samba.org
tridge at samba.org
Thu Feb 25 14:09:16 MST 2010
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
More information about the samba-technical
mailing list