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 [email protected] _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
