CMake (Re: GNU make version)

[Lubos Lunak]

On Wednesday 07 of March 2012, David Tardon wrote:
> On Wed, Mar 07, 2012 at 01:28:05AM +0100, Mat M wrote:
> > Hello
> >
> > Could someone point to archive on choosing gnumake ?
> > I am surprised cmake was not elected, since the C means
> > cross-platform, and that is one basic of LO.
>
> Sigh, life would not be complete without enthusiasts telling us we
> should switch to cmake (or Qt) every few months. So, please, go read
> http://wiki.services.openoffice.org/wiki/Build_System_Analysis for the
> basics and
> http://openoffice.2283327.n4.nabble.com/New-build-system-td2928559.html
> for more questions and answers.

 That comparison appears to be seriously biased towards gbuild (referred to 
as 'GNU Make' in the document).

 I'm not build system expert, but judging from my CMake experience in KDE, the 
information and conclusions for CMake are either outdated or just plain wrong 
(given the document dating to the time when KDE SC 4.4 had been released, 
thus CMake having been used for more than 2 years by that time, I assume it's 
the the latter). In particular:

- recursive make - CMake uses recursive make calls, but it appears the depth 
is always at most 3, and technically it's just one toplevel make calling make 
for each subtarget. I can also not see any of the recursive make problems 
with CMake, with the possible exception of performance. Specifically, doing 
make -j40 in kde-workspace/kwin really results in up to 40 jobs running at 
the same time, and dependencies are handled correctly. See also 
http://www.cmake.org/Wiki/CMake_FAQ#Other_Questions .

- starting from a dedicated directory - this is an utter nonsense, CMake 
allows very modular building. There are even a number of KDE applications (or 
even plugins) that normally build as a part of a larger whole, but not only 
each sub-part can be built, but the sub-directory can be put in a tarball and 
built separately that way, if done properly. Possibly whoever created the 
document considered CMake's ability to use a large number of small 
CMakeLists.txt files to be a problem, when it's in fact an advantage. It is 
also worth noting that gbuild does require starting from dedicated 
directories.

- no migration path - we right now build with two independent build systems, 
dmake and gbuild, so I don't see why CMake wouldn't be usable the same way. 
This is probably a result of the incorrect 'dedicated directory' assumption 
above. In practice CMake should build fine inside a different build system 
(that's just running 'make' there, right?) as well as the other way around 
(http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject , 
which can go as far as even downloading and configuring the external project 
first).

- explicit custom target dependencies - KDE uses a large number of custom 
source files (such as .kcfg files containing configuration options from 
which .cpp/.h files for handling them easily are generated) and they're built 
by simply using the right macro and mentioning the name there. Probably 
whoever wrote the comparison did not realize CMake has macros too.

 All in all, with the possible exception of performance problems due to 
invoking make more than once, about which I can't say reasonably certainly 
either way, the evaluation of CMake in that document appears to be completely 
flawed.

 Also, note that gbuild does not have a number of deficiencies listed, 
probably because they either were not known by the time or were not deemed 
important, such as lacking any usable documentation or the inability to 
detect even the most blatant developer mistakes like typos.

 Not that I expect people now suddenly jump with joy and start converting to 
CMake (as much I'm tempted to try it out for real, I think there are more 
important problems than having a homebrewn build system that seems to work 
good enough), but even handwritting Makefile files could have probably won 
such "fair" comparison.

-- 
 Lubos Lunak
 l.lunak at suse.cz