Hi, On Thursday 07 June 2007 15:45, Oliver Kullmann wrote: > Hello, > ... > 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).
You can detect directories and/or files with cmake, using IF(EXISTS) or FILE(GLOB). This way you can collect at cmake time the directories or files you want to build. If you then add a new file/directory, you will have to "touch" any of the cmake files to force cmake to run again if you enter "make" (or run cmake directly). But I would not recommend this (because people will forget to rerun cmake or to touch a file). You can make these things easier by creating your own high-level cmake macros. > 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.) Yes, because not all systems supported by cmake have a shell. So you better stay with cmake functions if you want to stay portable (which you don't want). If you want to call external programs, there are different ways in cmake: execute_process - at cmake time add_custom_command/add_custom_target - at build time > 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? Yes. But why would you care about helper files in your build tree ? But you can set up the directories where libraries and executables go explicitely by setting the EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH. ... > 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.) While it takes a bit to get used to, building out-of-source has many advantages and once your used to it you don't want to build in-source anymore. -you can have buildtrees for multiple configurations (release, debug) -no file goes into the source tree, so it stays completely clean -you can have buildtrees for different toolchains to check whether they work -you can simply remove the buildtree and rerun cmake so everything's fresh again You really should do it (I also hesitated in the beginning). > 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? CMake is not an extension to make, it is a cross-platform build-file generator (Makefiles, MSVC, XCode, KDevelop projects). It is powerful enough to build sophisticated projects like KDE4, so I doubt there is much it can't do. Bye Alex _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake