CMake (Re: GNU make version)
l.lunak at suse.cz
Wed Mar 7 03:57:11 PST 2012
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
> 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
- 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
- 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
which can go as far as even downloading and configuring the external project
- 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
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.
l.lunak at suse.cz
More information about the LibreOffice