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