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