Re: Unmet build dependencies: ninja-build

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Saturday 15 of May 2021 01:54:27 Slávek Banko via tde-devels wrote:
> BTW, before a long time I tested the creation of central CMakeLists.txt
> in tde-i18n - to allow all languages to be built by one CMake and make
> call. But with classic make it became completely unthinkable because
> every launch of classic make requested approximately 20 minutes before
> anything started. That is why I had to leave this idea at that time. Now
> I look forward to the same task I can test with ninja-build.

I mentioned tde-i18n as an example and now I have results here!

You can see two new PRs - first to add top-level CMake rules to tde-i18n 
and the second that these rules will be used when building deb packages:

https://mirror.git.trinitydesktop.org/gitea/TDE/tde-i18n/pulls/34
https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/pulls/85

Added top-level rules not only make a simpler building process, but at the 
same time it can increase efficiency because all targets of all languages 
are built together, while previously the individual languages were built 
as individual buildings.

With my earlier attempt, it turned out to be a big problem that for the 
classic make such a large number of targets is not manageable. This time I 
armed my patience and I measured it:

Building with ninja-build:
real    5m49.024s
user    40m58.768s
sys     4m24.916s

Building with classic make:
real    470m23.559s
user    4929m57.628s
sys     8m44.468s

Both were under completely equal conditions - the same chroot, on the same 
builder, both using top-level rules, both built by:

time dpkg-buildpackage -j12 -b 2>&1 | tee ../build.log

To build a deb package, there is one call for build and then individual 
calls to install individual languages. The problem is that for the classic 
make from the start of "make" until it starts to really do something, it 
passes around 20 minutes. To install more than 70 languages, it means more 
than 70× call make and wait every time. Therefore, internal overhead of 
classic make appears here with a huge scale. Therefore, ninja-build 
efficiency here is so significant.

When building using classic make, there was more advantageous when the 
builds of individual languages were individual builds because overhead 
depending on the number of targets was smaller. A large number of targets 
for classic make is just not manageable. Ninja build is definitely more 
advantageous. 

Cheers
-- 
Slávek

Attachment: signature.asc
Description: This is a digitally signed message part.

____________________________________________________
tde-devels mailing list -- devels@xxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devels-leave@xxxxxxxxxxxxxxxxxx
Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@xxxxxxxxxxxxxxxxxx

[Index of Archives]     [Trinity Users]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [KDE]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]     [Trinity Desktop Environment]

  Powered by Linux