How do you debug KDevelop in KDevelop?

Igor Kushnir igorkuo at gmail.com
Sun Mar 29 21:15:14 BST 2020


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


More information about the KDevelop-devel mailing list