CMake (Re: GNU make version)

[Michael Stahl]

On 07/03/12 12:57, Lubos Lunak wrote:
> 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.

indeed, and AFAIK most of the platforms are supported by CMake by way of
the (GNU) make backend.  what was your point again?  oh, GNU stands for
GNU's not UNIX, but we actually found that GNU make also works on UNIX
as well  :)

>> 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:

most of the people doing the comparison weren't build system experts
either, they just had a list of requirements that the current
dmake/build.pl system could not fulfill.  then they sought input from
build system experts on the tools at ooo mailing list, and the CMake
maintainer actually showed up there to discuss things.

> - 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 .

"with the possible exception of performance" was the main appeal of
non-recursive make for us.

> - 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.

sorry i don't have time to understand this point right now :)

> - 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).

actually i think i asked the CMake maintainer once (who posted on
tools at ooo) whether CMake allowed for having one mode to build a single
module, and another mode to build whole OOo; iirc i didn't get a
satisfactory answer.

> - 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.

that had been pointed out at the time, but really, what's the difference
between having to write lots of custom targets in CMake vs. GNU make?
the only problem could be that CMake (being at a higher level of
abstraction) doesn't offer something that some of our crazy custom stuff
would need, but that is just speculation.

>  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.

it would be great if we had had people with a lot of CMake experience 2
years ago to point out mis-understandings, but alas, they didn't
contribute to the discussion back then.

>  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

it would be great if developers didn't put so many regressions in LO so
i could have time to write gbuild documentation ;)

> the inability to 
> detect even the most blatant developer mistakes like typos.

there is a lot of typos gbuild can detect, e.g. try linking against a
non-existent library; what specifically are you missing?

>  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.

you are welcome to waste your time doing yet another CMake pilot (i can
even point you to the OOo CMake pilot CWS if i remember its ridiculous
name), but please don't expect anybody to become particularly excited
about it at this point in time.