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