[CMake] Is CMake powerful enough?

[Alexander Neundorf]

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