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 __________________________ _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake