[CMake] CMake Marketing

[E. Wing]

So here's my take on CMake.
Compared to what I've seen and used out there, I think CMake is
certainly one of the best. I hate autoconf/automake and was too stupid
to figure them out. If I could manage to get something to work on one
platform, it wasn't always the case it would work on another (Solaris
vs IRIX vs Linux vs FreeBSD vs Mac OS X). The "auto" didn't seem very
auto.

Furthermore, CMake's ability to generate native Visual Studio projects
(and now Xcode projects) is a major issue for me. KDevelop also
intrigues me, but I haven't had time to really learn it.

I also love CMake's out-of-source build feature. I hate mixing my
source and object files. But strangely, when I describe this feature
to others, I seem to get puzzled looks. One thing that is lacking is
that when new users use CMake for the first time, despite my
instructions, they always mess-up and do an in-source build. I don't
know if anything can be done about this, but at the very least, I
think CMake needs a dist-clean like function that strips away
everything that CMake generated.

SCons does seem to be the main competitor. I've never used SCons,
though I generally hear good things about it and believe it to be
true. But I do not know Python. I have done lots of Perl though in my
past. But I've done enough Perl that I cringe when I hear a major
asset of SCons is the fact that you can use the power of Python.
Unleashing and utilizing the power of Perl usually turned out to be a
not so good thing when you had a straight-forward task that should be
simple. I'm suspicious that Python would be the same way.

One thing that struck me with an SCons tutorial I was looking at was
there was some data "massaging" going on. (It's the classic trade-off
of domain specific languages vs. general purpose languages.) For
example, to express a list of files, they needed to put something in
an array data structure and later call split on the thing to massage
the data into a format that the system needed. I don't know if this is
typical of SCons or if the tutorial was just being silly, but I found
CMake a little more elegant in this regard where there seemed to be
less massaging and typing for the common cases.

But I think I'm a minority in these opinions. Generally I find with
the language wars, everybody wants and must do everything in their
native language. So SCons seems to get the backing of the entire
Python community.

Another thing I hear about SCons is that it doesn't do native Visual
Studio projects, but wrappers around nmake. I haven't confirmed this
myself, but if true, I don't find that very satisfying. The native
Visual Studio engineers I have to deal with would probably shoot me if
I made them give up their *real* IDE.

>From SCons users, I have heard that they hate the CMake language and
couldn't figure it out, and they've had problems with CMake's
dependency chain...things about the cache getting stale or corrupt too
frequently. I don't have any more specifics on this.


But from my personal stand point, there are things I dislike about
CMake too. Documentation is my biggest gripe. I think it's terrific
that there is an actual CMake book available for purchase which is one
of the things that sold me on CMake. And the documentation is way
better than most open source projects I've seen. But there is a
disconnect (in my opinion) between the documentation about CMake and
tutorials on how to use it. Reading the book didn't help me nearly as
much as I hoped in getting a serious project off the ground. I really
think the book needs to be extended (or have online tutorials) that
describe in a hand-holding way, how to write a real-world build system
from scratch. The project itself shouldn't be trivial, but need not be
horribly complex either. Perhaps a Cookbook approach could be useful
too. I find there are certain patterns in build systems that come up
again and again. If there was a recipe I could look up and paste in,
it would make life much easier.

My second gripe is the CMake language itself. This is partly because
of the lack of documentation. But the way the language looks and
behaves isn't like anything I've seen before. If CMake is based on
some other language, I would really like to know what that language is
so I can read up on it. For simple/common things where CMake has a
direct, built-in function or macro for the situation, I find CMake
very easy to use. But when I have to deviate from these built-ins and
start doing things with temporary variables and regular expressions, I
find that I am fighting the language. In my worst struggles, learning
Python starts looking very appealing.

My remaining gripes are Mac OS X centric, but these might be important
to marketing CMake. CMake has come farther than any other
cross-platform build tool in my opinion, but still not far enough. The
lack of OS X framework support is a serious sticking point for me. A
large number of open source projects out there are libraries, not
applications, so being able to build a framework is incredibly useful.
Being able to find/detect frameworks using the preexisting functions
like FIND_PATH/FIND_LIBRARY would be extremely useful too as you may
have seen the work-arounds in my Find*.cmake scripts I've submitted
are not pretty.

There is also the lack of Universal Binary support, but I trust this
will ultimately be addressed.

Also being able to pregenerate a stand-alone project that could be
copied to other systems would be a handy feature for OS X. On OS X,
paths are generally extremely predictable so this is actually possible
unlike Windows. Having an intermediate step of always having to run
CMake can be uninviting to new users who download some source code
they got on the internet for the first time. (Having to install CMake
is another issue, but there probably isn't much that could be done
about this.)


As for marketing, one thing that could be helpful is getting CMake
adopted in some other high profile cross-platform projects. I have
been contributing in an unofficial capacity to both SDL and
OpenSceneGraph with Xcode/OS X projects/builds. I grow very tired of
manually keeping the Xcode projects up-to-date with the other build
systems and have kicked around the idea of CMake. (This would also
help the Visual Studio side of things.) But we currently produce OS X
Frameworks and not dylibs so CMake fails to produce the solution we
need. If these features were implemented into CMake, it could
seriously influence adoption for both of these projects.

You should also know that currently OpenSceneGraph is starting to
think about migrating its build system. The two major proposals are
SCons and CMake. They said they would put up a Wiki to do a
side-by-side comparison tomorrow. This is certainly a good chance to
find out what people are interested in with a build system. And if you
want to help fill out information about CMake, that would probably be
helpful too. (And if you can resolve the Framework and Universal
Binary issues in the near/intermediate future, I think this could
almost cement the deal, though I am not in authority.)

Anyway, the osg mailing list can be found here:
http://openscenegraph.net/mailman/listinfo/osg-users

The current topic name is "Streamlining releases".

Thanks,
Eric