[tde-devels] Re: Unmet build dependencies: ninja-build

On Saturday 15 of May 2021 01:54:27 Slávek Banko via tde-devels wrote: 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