[CMake] Is CMake powerful enough?

Alan W. Irwin irwin at beluga.phys.uvic.ca
Thu Jun 7 16:49:59 EDT 2007


On 2007-06-07 20:45+0100 Oliver Kullmann wrote:

> 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.)

cmake can configure generated Makefiles to do most things you can do
directly with make.  I say "most things" because I don't want to
overgeneralize.  However, ADD_CUSTOM_COMMAND is essentially equivalent to a
make stanza with prerequisites (cmake file dependencies) and a rule
(command).  I have used ADD_CUSTOM_COMMAND to do all sorts of things (e.g.,
build docbook documentation, etc.) Does ADD_CUSTOM_COMMAND satisfy your
needs or do you need something more?

>
> A lesser problem (likely) seems to be that there is no really fine-grained
> control over where all those auxiliary files go?

True.

> 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").

The build tree is definitely messy compared with the install tree, but I
think you want the build tree since you can run "make" from subdirectories of
it (which is not the case for the install tree, of course.)  Also, you can
run ctest (or "make test") from the build tree (see below).

>
> 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.)

You can run "make" in sub-directories of the build_tree.  If you have set up
your cmake dependencies properly, then executables get updated properly
whenever the source tree is changed.  When CMakeLists.txt files are changed
in the source tree, this updating includes running cmake to get everything
up to date.  I always run cmake with a separate build tree so one set of
terminal windows is open in various sub-directories of the source tree and
one set in various sub-directories of the build tree, and I now think of
this as the natural way to develop.

Also, you mentioned testing.  For that, check out the ADD_TEST command. I
know ctest (or the equivalent "make test") works in the top directory of the
build-tree, and I assume it also works in subdirectories of that tree
although I haven't actually tried that.

I think you also mentioned distribution.  The cpack command is good for this,
but is not documented very well yet (however, see
http://www.cmake.org/Wiki/CMake:Packaging_With_CPack, and check out
the top-level CMakeLists.txt file for CMake itself which sets up CPack to
do all the various kinds of distributions of CMake itself).

In sum, it is quite possible that cmake is not right for your special needs,
but ADD_CUSTOM_COMMAND and ADD_TEST (as well as separate build-tree builds
and CPack) are extremely powerful features you should be familiar with
before you make a decision.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the CMake mailing list