Hi Chiheng,
CMake is a very great tool. But its drawback is also obvious. It
will consume large amount of time to generate Makefiles every time you
want to build, especially for ultra large projects. Building can be
parallelized, but the CMaking, like runing configure scripts, can't be
parallelized. So, the "caching" of Makefiles seems benefitial for
current and future mutil-cores systems.
Normal developers seldomly touch CMakeLists.txt. So, in very rare
condition, you need to regenerate the Makefiles.
As someone who just started using CMake (quite literally a few weeks
ago), I'm somewhat interested in your arguments. Personally, I don't
see many drawbacks and I must be missing something if they are
"obvious".
It is true that while developing software, using CMake requires an
extra step. For example, when you add a C++ source file, you'll need
to run cmake and then make. But after development, having your
software being usable across multiple platforms seems to be worth it.
If later on, you want to add a file, you don't have to modify the
Linux Makefile, the Mac Makefile, and the Windows Makefile. IMHO,
CMake saves the time of the developers.
After many years of writing Makefile files by hand, Autotools seemed
like moving 3 steps forward and 2 steps back. CMake seems to be a big
improvement. But CMake makes Makefiles and if you don't like it, you
can always stick with just Makefiles. When you get tired of that,
then you'll be glad that both Autotools and CMake are available
options for you...
Ray
PS: Your example of parallel compilation doesn't take into account
that only the files that change need to be recompiled. And then when
the executable is to be re-linked, the object files have to be placed
on the same disk, etc. I don't know if CMake supports parallel
compilation (i.e., for n processors, generate n Makefiles so that each
CPU is responsible for just their parts), but that would be cool...
:-)