Re: How do you debug KDevelop in KDevelop?

Igor Kushnir <[email protected]>
Newsgroups gmane.comp.kde.devel.kdevelop
Message-ID <[email protected]>
Hi Sven,

On 2020-03-29 13:48, Sven Brauch wrote:
> do you already build with ninja, i.e. cmake -GNinja ...?
> For me, ninja is so fast in detecting what has changed that it doesn't really
> matter if everything is rebuilt.

I just tried Ninja and the difference is striking!

I created two new build configurations almost the same as described in 
my original email. The first difference is in the "Configure 
environment" combobox: I'm just using the default environment without 
custom QML2_IMPORT_PATH and QT_PLUGIN_PATH variables in both new 
configurations. The second difference is: one of the new configurations 
has -GNinja in the "Extra arguments" field, the other one has -G "Unix 
Makefiles" (I had to specify Make explicitly because after I installed 
Ninja and created a -GNinja configuration, KDevelop picked Ninja instead 
of Make when the "Extra arguments" field was empty).

With GNU Make building after a typical small change takes about 12 
seconds. For somewhat more significant changes (e.g. a header change) it 
takes 13-15 seconds. After a change in a CMakeLists file it took 20 
seconds. Incremental installing takes about 10 seconds.

With Ninja the 12 seconds become 5.5-6 seconds. 13-15 change into 6-9.
And 20 becomes 12. Incremental installing with Ninja takes 2 seconds.

In conclusion, Ninja makes incremental builds two times
faster on average and incremental installation 5 times faster.

By the way, I noticed that cmake silently starts its work immediately 
when a CMakeLists file is changed. So if I wait for 10 seconds after 
changing CMakeLists.txt before making an incremental build, the build 
time becomes the same as after a typical small C++ code change.

Note that there are KDevelop bugs (configuration errors, freezing) when 
switching between Make/Ninja build configurations and directories. On 
the other hand, I have no reason to go back to Make now that I've done 
the benchmarking.

> Other than that, I tend to debug the same build of KDevelop as I'm running
> anyways to avoid problems with global and local installations mixing.

I have no mixing installations problems with the setup I described in my 
first email. I can easily switch between master/5.5, Debug/Release, 
QtWebKit/QtWebEngine builds without touching the system KDevelop version 
or restarting the KDevelop process, from which I'm 
editing/building/debugging.

Thank you again for the very helpful Ninja tip,
Igor
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.