Michael Howard via tde-devels wrote:

On 14/05/2021 20:36, deloptes wrote:

...

Why is ninja-build now required?

dpkg-checkbuilddeps: error: Unmet build dependencies: ninja-build dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting

Not a good sign!!!!!!!!!!

I personally want to know why it was decided to use it. The promise that it is faster - I do not really believe - may be 20%. Did someone do a benchmark?

thanks

Michael Howard via tde-devels wrote:

Personally, I don't want to 'depend' on anything remotely linked to Google, and I wont be.

Simples.

but nobody asked you or me :)

Michael Howard via tde-devels wrote:

Uhm, now where have I come across that before? Debian springs to mind :-)

Modern way of democracy :)

Hi to all, Emanoil, Michael,

the question of change from classic make to ninja-build we discussed with Michele in jabber room during pull requests TDE/tde-packaging#79 and TDE/tde-packaging#81. See:

https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/pulls/79 https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/pulls/81

Ninja-build has been successfully used for a long time as the default for our CMake builds on FreeBSD. During testing on deb packages, I observed, for example, the acceleration of tde-i18n building from 20 to 10 minutes, tdelibs for armhf from 25 to 19 minutes. It is obvious that ninja-build can better deal with a large number of build targets and parallel building compared to classic make.

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.

Don't forget that I have to build many packages for many distributions and architectures on my builders. Therefore, every acceleration is useful. The ninja-build package is already part of Debian from Jessie. Therefore, we did not expect any complications to prevent change. In any case, classic make support is not canceled. If you remove ninja-build from Build-Depends in "control" file, the classic make will be used automatically.

Hi all, on top of Slavek's comment, ninja-build is just another tool that is available out there. We looked at pros/cons and in the end it provide a decent improvement on build times. So if a tool is good to make TDE better, it is definitely worth considering it. The same was for gitea, weblate, cmake and so on.

To be honest, I was a bit surprised to see such strong response on the mailing list for a relatively small change. End users won't see much of a different, packages are the same. And the build logic is done by cmake in the same way. ninja-build is just a worker doing what cmake tell it to do, just it does the job faster than make and with better progress feedback. And even at 20%, it is a considerable time gain when you have to build for 40-60 distro/arch pais (I don't even know the exact number now, Slavek can confirm that is needed - but it is a lot of building for sure :-) ).

In the end, we want to do what we believe is best for TDE while maintaining the TDE spirit and philosophy. I don't see "moving to ninja-build" breaking either of them. Am I wrong?

Cheers Michele

On 2021/05/15 04:03 PM, deloptes wrote:

...

In the end, we want to do what we believe is best for TDE while maintaining the TDE spirit and philosophy. I don't see "moving to ninja-build" breaking either of them. Am I wrong?

Of course not - as mentioned my question is what is motivation behind and numbers. The numbers match my observations. The thing is that we still have to learn, understand and get used to the changes anyway. ____________________________________________________

Hi all, In hindsight, it would have been more appropriate if we had sent an email to the devel ML informing everyone of the change from make to ninja build as default for DEB-like distros. It didn't come to our mind, apologies for that :-) As Slavek mentioned, you can still build using make if you wish, just get rid of the ninja-build dependency in the debian/control file.

Cheers Michele

On Saturday 15 of May 2021 18:05:04 deloptes wrote:

Michele Calgaro via tde-devels wrote:

...

Hi all, In hindsight, it would have been more appropriate if we had sent an email to the devel ML informing everyone of the change from make to ninja build as default for DEB-like distros. It didn't come to our mind, apologies for that :-) As Slavek mentioned, you can still build using make if you wish, just get rid of the ninja-build dependency in the debian/control file.

I have seen the merge of the PR, but as said before I was curious about the why. IMO you are the bosses and proven to take good decisions. I do not think it is necessary to inform in advance or to apologies for that. I was just surprised by the hard dependency. I am not sure if it can be done via recommendation. If it can work as before without ninja-build, why the hard dependency? But it is still OK for me - important is that the code works at the end.

---

Because here is an intention to use ninja-build as the default for building deb packages, it was necessary to add ninja-build in "control" files to Build-Depends to ensure the installation of ninja-build package. It is simply not possible to make an dependency optional for such a case, bacause the package building conditions must be unambiguous.

Cheers

On 15/05/2021 01:56, Michele Calgaro via tde-devels wrote:

...

Hi to all, Emanoil, Michael,

the question of change from classic make to ninja-build we discussed with Michele in jabber room during pull requests TDE/tde-packaging#79 and TDE/tde-packaging#81. See:

https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/pulls/79 https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/pulls/81

Ninja-build has been successfully used for a long time as the default for our CMake builds on FreeBSD. During testing on deb packages, I observed, for example, the acceleration of tde-i18n building from 20 to 10 minutes, tdelibs for armhf from 25 to 19 minutes. It is obvious that ninja-build can better deal with a large number of build targets and parallel building compared to classic make.

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.

Don't forget that I have to build many packages for many distributions and architectures on my builders. Therefore, every acceleration is useful. The ninja-build package is already part of Debian from Jessie. Therefore, we did not expect any complications to prevent change. In any case, classic make support is not canceled. If you remove ninja-build from Build-Depends in "control" file, the classic make will be used automatically.

Hi all, on top of Slavek's comment, ninja-build is just another tool that is available out there. We looked at pros/cons and in the end it provide a decent improvement on build times. So if a tool is good to make TDE better, it is definitely worth considering it. The same was for gitea, weblate, cmake and so on.

To be honest, I was a bit surprised to see such strong response on the mailing list for a relatively small change. End users won't see much of a different, packages are the same. And the build logic is done by cmake in the same way. ninja-build is just a worker doing what cmake tell it to do, just it does the job faster than make and with better progress feedback. And even at 20%, it is a considerable time gain when you have to build for 40-60 distro/arch pais (I don't even know the exact number now, Slavek can confirm that is needed - but it is a lot of building for sure :-) ).

In the end, we want to do what we believe is best for TDE while maintaining the TDE spirit and philosophy. I don't see "moving to ninja-build" breaking either of them. Am I wrong?

From my perspective, yes.

Hey, I can live without TDE, I'll just move on to another desktop. The link to Google, however tenuous, is too much for me.

On 15/05/2021 11:21, deloptes wrote:

Michael Howard via tde-devels wrote:

...

From my perspective, yes.

Hey, I can live without TDE, I'll just move on to another desktop. The link to Google, however tenuous, is too much for me.

That the guy developing this tool is employee @Google does not mean that the tool is made deliberately by Google. Why the hassle?!

It might, it might not but the link, however tenuous, is there. Why the hassle? Choice and a dislike of unilateralism.

If you are concerned, please review the code of ninja-build and give me/us something that would prove you are right. We are not in the middle ages yet.

I have no intention of reviewing ninja-build code. Far too many better things to do.

We all would benefit if one has a concern and would review the code. I have many concerns regarding the Linux OS and it is not developed by Google employees but you and I still use it.

The fact it is not developed by Google helps me a lot :) I wont go into my reasons for not trusting or liking Google, far too many of them as well.

Out of curiosity - what kind of mobile OS are you using?

That's my business but I assume your point is Android?

Anyway, I have been building TDE for many, many years, writing my own build scripts,  particularly for arm and before any arm architectures existed in TDE. I've built using cross-compilers and natively on devices that were  VERY 'sluggish' so the time taken/saved is no concern to me.

I've had to focus on life issues for the past couple of years so have had to neglect my hobbying. Anyway, in the short term, as Slávek says, the control file can be edited to remove the dependency.

These things though have a habit of creeping and maybe the point will come when 'classic' make can't be used.

Hey, as long as I can continue to not depend on ninja this or ninja that, I'm happy.

On Saturday 15 of May 2021 12:44:28 Michael Howard via tde-devels wrote:

Anyway, I have been building TDE for many, many years, writing my own build scripts,  particularly for arm and before any arm architectures existed in TDE. I've built using cross-compilers and natively on devices that were  VERY 'sluggish' so the time taken/saved is no concern to me.

I've had to focus on life issues for the past couple of years so have had to neglect my hobbying. Anyway, in the short term, as Slávek says, the control file can be edited to remove the dependency.

These things though have a habit of creeping and maybe the point will come when 'classic' make can't be used.

Hey, as long as I can continue to not depend on ninja this or ninja that, I'm happy.

Because the building of one source repository for me in R14.0.10 was 63 binary builds, there is very important for me to build it as efficiently as possible.

We first solved the problems that were with parallel builds in order to effectively use multi-core systems. The next step is the conversion from automake to CMake because CMake builds are more efficient than automake. Using ninja-build enabled us very easy to get further efficiency. Simply because ninja-build can do the same work better than the classic make.

You can remember the time when after freezing the source code, it took a month or more for everything was built. Thanks to parallel builds and CMake conversions, we managed to shorten the time to build to two weeks. For R14.0.10 we managed to complete the builds in one week. It is likely that the use of ninja-build will allow us another shortening.

It is great that CMake can generate classic makefiles as well as build file for ninja-build. There is only the use of the appropriate option for call CMake. As a result, full support remains equivalent to both - classic make as well as ninja-build. There is no intention to do some limitations. The only thing that was done is the selection of ninja-build as the default for official builds. You can build with the build tool that you prefer.

Cheers

On 2021/05/20 11:32 AM, deloptes wrote:

Slávek Banko via tde-devels wrote:

...

Don't forget that I have to build many packages for many distributions and architectures on my builders. Therefore, every acceleration is useful. The ninja-build package is already part of Debian from Jessie. Therefore, we did not expect any complications to prevent change. In any case, classic make support is not canceled. If you remove ninja-build from Build-Depends in "control" file, the classic make will be used automatically.

Slavek, how removing the dependency on ninja-build from Build-Depends will for cmake to use the classical make?

With ninja-build it is harder to debug .. how can I debug the build process and use classical make, but keep ninja-build install?

thank you

Hi Emanoil, https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html

you can probably force the use of a specific generator when you want to build it manually for debugging. I have not tested it though, so maybe I am wrong.

Also have a look at _cdbs_class_cmake in debian-tde.mk in packaging files, based on its value either make or ninja is used (Slavek correct me if I am wrong here).

Cheers Michele

On Sun, May 23, 2021 at 8:25 PM Slávek Banko via tde-devels < devels@trinitydesktop.org> wrote:

Dne ne 23. května 2021 09:43:07 Michele Calgaro via tde-devels napsal(a):

...

On 2021/05/20 11:32 AM, deloptes wrote:

...

Slávek Banko via tde-devels wrote:

...

Don't forget that I have to build many packages for many distributions and architectures on my builders. Therefore, every acceleration is useful. The ninja-build package is already part of Debian from Jessie. Therefore, we did not expect any complications to prevent change. In any case, classic make support is not canceled. If you remove ninja-build from Build-Depends in "control" file, the classic make will be used automatically.

Slavek, how removing the dependency on ninja-build from Build-Depends will for cmake to use the classical make?

With ninja-build it is harder to debug .. how can I debug the build process and use classical make, but keep ninja-build install?

thank you

Hi Emanoil, https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html

you can probably force the use of a specific generator when you want to build it manually for debugging. I have not tested it though, so maybe I am wrong.

Also have a look at _cdbs_class_cmake in debian-tde.mk in packaging files, based on its value either make or ninja is used (Slavek correct me if I am wrong here).

Cheers Michele

Yes, Michele mentions it correctly. In our common CDBS rules debian-tde.mk you can see that in the case of the existence of ninja binary, MAKE and Ninja generator in DEB_CMAKE_NORMAL_ARGS is set. These values need to be set together.

When we prepared it, we did not think about a variable, using which it would be possible to disable the use of Ninja, even if it is present. As the easiest way is before building to edit the line in debian-tde-mk:

ifneq "$(wildcard /usr/bin/ninja)" ""

When you change the name of the binary, for example to "/usr/bin/ninja-", the binary will not be found and Ninja will not be used.

BTW, what do you observe the problem using Ninja build in connection with the debuging?

Thank you for explanations - the problem is it tires to build everything until the end and it does not stop after failure. I guess it is not a big problem - but need to get familiar or be able to switch it off when needed.

BR

...

Thank you for explanations - the problem is it tires to build everything until the end and it does not stop after failure. I guess it is not a big problem - but need to get familiar or be able to switch it off when needed.

BR

Ninja has an argument '-k' where it should be '1' as the default value. This means that when an error occurs, there should be waiting only to complete the already running parallel jobs. This is the same as with classic make:

-k N keep going until N jobs fail [default=1]

Cheers

You can also build selective targets when doing manual builds for debugging instead of doing a full build. That is much quicker. ninja -t targets gives you all the available targets and then you can select the one you want to run.

It will take a bit of reading to get used to ninja, but overall I find it more flexible/powerful than make. And it is definitely quicker :-)

Finally, if you need coloring for the output, you can read here. https://medium.com/@alasher/colored-c-compiler-output-with-ninja-clang-gcc-1... We already have FORCE_COLORED_OUTPUT in cmake module, but it is not enabled by default.

Cheers Michele

Slávek Banko via tde-devels wrote:

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.

I agree - additional and major gain - for me was the purchasing of SDDs :)

BTW you could perhaps help us with overwriting target :) when we are in the discussion anyway :) https://mirror.git.trinitydesktop.org/gitea/deloptes/tdebluez/pulls/1

thank you, Slavek