2015-06-07 14:19 GMT-06:00 Justin Lecher (jlec) <j...@gentoo.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 07/06/15 22:14, Johannes Huber wrote:
>> Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny:
>>> Hello, developers.
>>
>> Hello Michal,
>>
>>> As you probably know already, CMake sucks a lot. One of its more
>>> sucky features is that it generates Makefiles that fail a lot. In
>>> particular, they fail at verbose build logs that are cluttered
>>> with useless CMake intermediate commands and hard to read. But
>>> also they sometimes deadloop hard in faulty dependency scanning
>>> [1].
>>>
>>> Those two issues can be solved by switching CMake to use Ninja
>>> instead of make. As you may know, Ninja is the fancy building
>>> tool that is faster and much harder to use than make. However, it
>>> integrates with CMake much better and with less hackery. In
>>> particular, the verbose build log is free of useless CMake
>>> percentage printing output and other non-sense, and contains only
>>> real build commands. It also gets dependency scanning right.
>>>
>>> Sadly, there are two problems with using Ninja:
>>>
>>> 1) it will not work with some packages,
>>>
>>> 2) it introduces an extra dep (on Ninja).
>>>
>>> The first issue is a bit complex. Sometimes the problem lies in
>>> CMake itself (not all CMake magic works in Ninja for some
>>> reason), sometimes in the project (relying on Makefile stuff),
>>> sometimes in the ebuild. For example, with Ninja you can't do '-C
>>> subdirectory' to run targets from a specific subdirectory. So, we
>>> can't force Ninja everywhere.
ninja has a "-C" option, too, but cmake only generates one build.ninja
in the root directory instead of a Makefile in every directory which
has a CMakeLists.txt.
>>>
>>> The second issue is a bit easier. GNU make is part of @system,
>>> ninja would be considered an extra package being installed. Do we
>>> consider it fine to require it randomly? Or do we need to justify
>>> the extra dep by benefits of building a particular package with
>>> Ninja? Is sane verbose build log a good enough benefit?
>>>
>>> So, what do you think? Should I start switching random packages
>>> to Ninja whenever it works?
>>>
>>> Oh, and this would be done via something like: :
>>> ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
>>>
>>> before inherit line. To respect user forcing another generator,
>>> and to get deps right.
>>>
>>> [1]:https://bugs.gentoo.org/show_bug.cgi?id=546336
>>
>> KDE herd maintains ~1000 packages and the majority relies on CMake.
>> I am not aware of any reports about GNU make related build files.
>> So i would vote for the reliable GNU make generator.
>>
>
> I tested ninja some while ago on some big cmake science projects and I
> found it to be faster. So I would vote for Micheals suggestion. Though
> I also never faced any problems with the makefiles either. It's purely
> that I found ninja to work smooth and fast.
Right after this feature was implemented (bug #430608), ago did some
testing on kde-base/kdelibs, but only found a 40 sec save on a 6min
overall build.
Christoph
>
> Justin
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0
>
> iQJ8BAEBCgBmBQJVdKc1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
> OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiDBQP/R2vvdQGBOUGHX5wNHCjJxoy
> XPQdJq7Y+ihrDj+630/EIzvncZjLXpJ1r03ftfQ8Km38m1dIL9HHVIX4Z6NHokwe
> bmEs1VAQk+3NajmzB4Wt6xJoiIPiQiIDeNLAYhe8MVL1qK+LW5sgC8gV7PWwau7b
> 7CsBbPJOE1Y/rcjc8B3c630hE8WXAfQ1lnIBR7EzNsnNwTp5s8F4u7JktZSKkSSc
> g1545i8EBaV2eHeEatIqEpB2oGDp2eDZjeLny7nlCU0FO0MfFFsTWBXEJHUDIto4
> ammwydyWLGBACU97jBkoePgSp54ekAW3XdtMFG9KT7/rArtgDY06wWFH2BqA0tcx
> qYGXqT1QBzjjUmTyQmHflKv3Zx233RD2h4J2g9A0wE5CKZViKdfKWADG0tyIRlOI
> ooZKj7sp/iKZbgQqVdHPqySw7clUFi0LGUr7RQr/RUC1z+ROSb+x+dCkSV9ujPSF
> A8acKoEu7cjjGU4P/RFiWbHR/czMXiv21VmAvD4sdqibkYlfR/YWyctz0JMzfIdz
> tB6ZDpedB3Qsu0tTdlnOYiCMpoMH/ZBK3vjLcG/72BkqjyyD32xJu1KVVARao+ZQ
> 4cOxNXDA35yeOnZ77pNLNhkS8CToGuijqtUdkDhYq+rhLFOkNcTbl+fR88UuTeAH
> ZwGZmZGkP1jubaDIN+NL
> =17Cu
> -----END PGP SIGNATURE-----
>
--
Christoph Junghans
http://dev.gentoo.org/~ottxor/
