14 May
2021
14 May
'21
7:36 p.m.
Why is ninja-build now required?
dpkg-checkbuilddeps: error: Unmet build dependencies: ninja-build
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied;
aborting
regards
8:11 p.m.
Michael Howard via tde-devels wrote:
On 14/05/2021 20:36, deloptes wrote:
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
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!!!!!!!!!! 
8:17 p.m.
On 14/05/2021 21:11, deloptes wrote:
Michael Howard via tde-devels wrote:
Personally, I don't want to 'depend' on anything remotely linked to
Google, and I wont be.
Simples.
--
Michael Howard.
On 14/05/2021 20:36, deloptes wrote:
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
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!!!!!!!!!!
10:26 p.m.
On 14/05/2021 22:07, deloptes wrote:
Michael Howard via tde-devels wrote:
Uhm, now where have I come across that before? Debian springs to mind :-)
--
Michael Howard.
Personally, I don't want to 'depend'
on anything remotely linked to
Google, and I wont be.
Simples.
but nobody asked you or me :)
____________________________________________________
11:54 p.m.
On Friday 14 of May 2021 21:36:26 deloptes wrote:
Why is ninja-build now required?
dpkg-checkbuilddeps: error: Unmet build dependencies: ninja-build
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied;
aborting
regards
____________________________________________________
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.
Cheers
--
Slávek
15 May
15 May
12:56 a.m.
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
7:03 a.m.
Michele Calgaro via tde-devels wrote:
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 :-) ).
"strong response" is a bit strong
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.
10:39 a.m.
On 2021/05/15 04:03 PM, deloptes 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.
Cheers
Michele
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.
____________________________________________________
4:05 p.m.
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.
11:27 p.m.
On Saturday 15 of May 2021 18:05:04 deloptes wrote:
Michele Calgaro via tde-devels wrote:
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
--
Slávek
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.
____________________________________________________
16 May
16 May
4:05 a.m.
On 2021/05/16 01:05 AM, deloptes wrote:
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.
TDE is a team effort. Some people are more active, some less, but all contributions are
equally important and welcome :-)
Let's continue to work together in making TDE great!!
Cheers
Michele
15 May
15 May
7:29 a.m.
On 15/05/2021 01:56, Michele Calgaro 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.
--
Michael Howard.
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?
10:21 a.m.
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?!
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.
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.
Out of curiosity - what kind of mobile OS are you using?
10:44 a.m.
On 15/05/2021 11:21, deloptes wrote:
Michael Howard via tde-devels wrote:
It might, it might not but the link, however tenuous, is there. Why the
hassle? Choice and a dislike of unilateralism.
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?!
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.
--
Michael Howard.
10:48 a.m.
On 15/05/2021 11:44, Michael Howard via tde-devels wrote:
On 15/05/2021 11:21, deloptes wrote:
Oops. Sorry, I meant arm repos.
--
Michael Howard.
Michael Howard via tde-devels wrote:
It might, it might not but the link, however tenuous, is there. Why
the hassle? Choice and a dislike of unilateralism.
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?!
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.
11:17 p.m.
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
--
Slávek
20 May
20 May
2:32 a.m.
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
23 May
23 May
7:43 a.m.
On 2021/05/20 11:32 AM, deloptes wrote:
Slávek Banko via tde-devels wrote:
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
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
6:23 p.m.
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:
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?
Cheers
--
Slávek
Slávek Banko via tde-devels wrote:
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 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
24 May
24 May
12:08 a.m.
On Sun, May 23, 2021 at 8:25 PM Slávek Banko via tde-devels <
devels(a)trinitydesktop.org> wrote:
Dne ne 23. května 2021 09:43:07 Michele Calgaro via
tde-devels napsal(a):
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
On 2021/05/20 11:32 AM, deloptes wrote:
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?
Slávek Banko via tde-devels wrote:
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 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
12:22 a.m.
On Monday 24 of May 2021 02:08:49 deloptes wrote:
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
--
Slávek
On Sun, May 23, 2021 at 8:25 PM Slávek Banko via
tde-devels <
devels(a)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:
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? 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
1:44 a.m.
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
25 May
25 May
11:37 p.m.
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
26 May
26 May
5:40 a.m.
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
1064
days inactive
1076
days old
26 comments
4 participants
participants (4)
-
deloptes -
Michael Howard -
Michele Calgaro -
Slávek Banko