| 1 |
Christoph Junghans posted on Sun, 07 Jun 2015 20:08:25 -0600 as excerpted: |
| 2 |
|
| 3 |
> 2015-06-07 14:19 GMT-06:00 Justin Lecher (jlec) <jlec@g.o>: |
| 4 |
>> |
| 5 |
>> On 07/06/15 22:14, Johannes Huber wrote: |
| 6 |
>> |
| 7 |
>>> Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny: |
| 8 |
>>> |
| 9 |
>>>> CMake sucks a lot [but will suck less if we switch] CMake to use |
| 10 |
>>>> Ninja instead of make. As you may know, Ninja is the fancy building |
| 11 |
>>>> tool that is faster and much harder to use than make. However, it |
| 12 |
>>>> integrates with CMake much better and with less hackery. |
| 13 |
|
| 14 |
>>>> GNU make is part of @system, ninja would be considered an extra |
| 15 |
>>>> package being installed. Do we consider it fine to require it |
| 16 |
>>>> randomly? |
| 17 |
|
| 18 |
>>> KDE herd maintains ~1000 packages and the majority relies on CMake. |
| 19 |
>>> I am not aware of any reports about GNU make related build files. So i |
| 20 |
>>> would vote for the reliable GNU make generator. |
| 21 |
>>> |
| 22 |
>> I tested ninja some while ago on some big cmake science projects and I |
| 23 |
>> found it to be faster. So I would vote for Micheals suggestion. Though |
| 24 |
>> I also never faced any problems with the makefiles either. It's purely |
| 25 |
>> that I found ninja to work smooth and fast. |
| 26 |
|
| 27 |
> Right after this feature was implemented (bug #430608), ago did some |
| 28 |
> testing on kde-base/kdelibs, but only found a 40 sec save on a 6min |
| 29 |
> overall build. |
| 30 |
|
| 31 |
That's still 10-11% (depending on what side of 6 minutes the 40 seconds |
| 32 |
goes), a pretty sizable difference considering it's just the maker we're |
| 33 |
fiddling with, not the compiler. |
| 34 |
|
| 35 |
[TL;DR summary: yes to marking packages and automating ninja where safe |
| 36 |
for users that want to, but please keep gnu make the default.] |
| 37 |
|
| 38 |
And on those ~1000 kde packages, for live users with ccache cutting |
| 39 |
compile time and thus speeding overall builds, the figure is likely to be |
| 40 |
MUCH higher than 10%. WAG of 50%? Anyone? |
| 41 |
|
| 42 |
That said, I'm conservative enough to lean toward gnu make as well, |
| 43 |
certainly by default. But were there a standardized ebuild flag to mark |
| 44 |
it ninja compatible, and a documented way to change that default, I'd |
| 45 |
also almost certainly try ninja, particularly when I /am/ doing live-kde |
| 46 |
as I was for a couple years with kde4, and probably will be again with |
| 47 |
kde5 once I can actually get kwin5 working long enough on my hardware[1] |
| 48 |
and eventually find kde5 stable enough of a base to run live again. |
| 49 |
|
| 50 |
So marking ebuilds that can use ninja successfully and automating it so |
| 51 |
people that want to can, great, and by all means, document it well so |
| 52 |
they know they can, but please, gnu make default for now. |
| 53 |
|
| 54 |
--- |
| 55 |
[1] kwin5 working: I've tried several times over the last year, always |
| 56 |
getting the same kwin5 crash/respawn loop and thus being unable to get |
| 57 |
any further into kde5 testing. FWIW single-card radeon turks graphics, |
| 58 |
triple monitor, native kernel/mesa/xorg driver, works fine with kwin4 in |
| 59 |
OpenGL mode. |
| 60 |
|
| 61 |
-- |
| 62 |
Duncan - List replies preferred. No HTML msgs. |
| 63 |
"Every nonfree program has a lord, a master -- |
| 64 |
and if you use the program, he is your master." Richard Stallman |
Archives