[CMake] Is CMake powerful enough?

[Oliver Kullmann]

Hello,

We are currently in the process of evaluating whether we shall/can
update our build system from make to cmake. We see several problems,
which we would like to post here, hoping about enlightenment
on how to solve these problems (or not(!)).

Perhaps a few words about the project: It's about a generative
C++ library for some area of "hard problem solving" (SAT solving,
to be precise, but this shouldn't matter here). Furthermore
it is an "active library", where using it means extending it,
and where the library provides much more services than just
header files (and link-libraries); this includes a "higher-order"
test system, a performance measurement system, documentation building,
automatic release etc. The point here is that the build system
is used permanently by the users of the library, for all
sorts of tasks (not just using it once as in "configure; make; make install").

We are "mainly computer scientists", i.e., we cannot afford to be taken
hostage by arcane technical details, but we need a more abstract, well-defined
system, where we can afford to not working on it, say, for half-a-year,
and after returning still after a few hours we can continue working on it.
That's the problem with the make-system: There are so many peculiarities,
that it's truly a pain maintaining it (especially extending it).
So the hope is to find in cmake a powerful *meta-make*, by which
we can create in a more abstract way, having more powerful tools at hand,
the underlying make-files.

Everybody involved creating a generative C++ library likely makes
the experience, that it's not so easy, so to make life easier otherwise,
1. we support only Linux,
2. we do not care about any software dependencies, but the system
   builds locally all required software (compiler, Boost, database, etc.)
   itself.

Now to the problems we see:

The directory structure is "fractal" (or "recursive") and "dynamic", so
for example modules have subdirectories Module/tests, containing generic
tests for the components provided by the modules, where Module/tests might
contain a tests-subdirectory itself for testing the testsystem etc.; additions
are detected automatically, no registrations whatsoever is required for tests,
but by running "make check" all new or changed tests are compiled and executed
(of course, the produced link-libraries, executables, text files etc. are
stored in some other directory-hierarchy, similar to the source-hierarchy, but,
of course, also with many differences).
So in the first stage stage of the the build process here, from configuration values, 
parameter values, targets given and the current state of the file-system we need
to compute dynamically the list of second-stage-targets and -rules, and then we need
to run make (this is actually achieved by the 2-stage-process of make itself,
but it's quite clumsy).

It appears now that the computational power of cmake is rather restricted?
There seem to be no functions?? (While we had hoped that there are many
more than in make?) Even just a shell-call seems to need to be programmed
by ourselves?? (I can't believe that, but couldn't find it.)

A lesser problem (likely) seems to be that there is no really fine-grained
control over where all those auxiliary files go? It seems the basic assumption
is that of having a build-directory (used only once), where all sort of stuff
can be dumped to, and then with the final "make install" the "relevant"
files are moved elsewhere? This does not neatly fit with our permanent use
of the build-system, but likely one could live with it (by automatically
always running "make install").

Another, perhaps more serious problem: We are exploiting the tree structure of
the library, that is, at every point in the tree when calling make exactly
the sub-tree at this node is considered (everything down, nothing up).
This works very well for example for testing first the local module (we use
continuous testing), then going one step up (which needs more time), and before
having a break we run "make check" at the root of the (source-)tree. To avoid cluttering
the library with many makefiles, at every node (of the source-tree!) there sits only a *link*
to one generic makefile (so we have only *one* makefile!), and that's it.
Now the cmake model seems to be, that either you clutter your source-tree with
make-files, and then you get the binaries etc. delivered to the source tree (we
don't want that), or you create the make-files in the "build-tree", but then
you have to operate in that tree, not in the source-tree?!? (We find it very
convenient to only work in the source-sub-directory we are currently concerned
with, and the build system directs all output to the right places (somewhere
else); and having to "be" at two different places at the same time, in the
source-directory and in the related "build-directory", might open the
possibility for subtle bugs.)


Finally, it somehow seems to us that the conception of cmake is not really that
of a powerful extension of make, but more of a convenient "user-interface", with
the typical trade-off: What the user-interface does, it does convenient and well,
but what it not does is very hard to integrate?

----------

We would be thankful for any comments!

Oliver

-- 
Dr. Oliver Kullmann
Computer Science Department
University of Wales Swansea
Faraday Building, Singleton Park
Swansea SA2 8PP, UK
http://cs-svr1.swan.ac.uk/~csoliver/