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@suse.cz
Context
R: Errror building LO lang=it - windows / cygwin · walter
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.