| After reading your reply, I have browsed the cmake reference manual. It is likely that for many people cmake may be enough, but my homegrown makefile system can do much more than cmake. The cmake equivalent for the makefiles with compilation-target-dependent definitions is called a toolchain file. However, unlike for make, where I have complete freedom, cmake allows in the toolchain file only a relatively small set of options from a closed set. Because I cross-compile for many unusual combinations of embedded CPUs and operating systems, with cmake I would certainly need to write many custom toolchain files, but cmake would not allow me to specify everything that I need. Besides C & C++, I use many less popular programming languages. Even if cmake supports a decent number of programming languages, when you want to use any language that is not on the currently supported list, you are out of luck. With my make system, if I decide to use a new programming language, I would need only a few minutes to update the makefile with generic rules and the toolchain makefiles in order to be able to build a project with the new language. Why would I need to use a rigid tool like cmake, when the same and more can be done with make ? I see in the cmake documentation the following recommendation, which appears to have been followed in all the cmake projects that I have seen. "We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate." This recommendation is very wrong.
Even if cmake has the limitation that it is triggered only by an updated CMakeLists.txt file, the workaround is not to avoid using GLOB. The correct workaround is to use GLOB, but to also execute the command "touch CMakeLists.txt" whenever there are changes in the set of source files. Executing a "touch" is much simpler than editing CMakeLists.txt. The fact that the bad recommendation from the cmake documentation has been followed blindly in all the cmake projects that I have seen is one reason why I thought that cmake sucks. However, like I have said above, even when cmake is used correctly, it is too rigid for those whose applications are not restricted to the targets understood by cmake. "make" does not have any such limitations, so I still do not see any reason for the existence of "cmake", because to do what cmake does you do not need a new executable, you need just a set of generic makefiles, like those that I use, or like those that are used in some projects like FreeBSD (those, unlike cmake are not oriented towards multiple compilation targets, but they could be adapted for such a purpose with much less effort than writing a program like cmake). |