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