How do you debug KDevelop in KDevelop?

[Milian Wolff]

On Sonntag, 29. März 2020 22:15:14 CEST Igor Kushnir wrote:
> 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!

Yes!

<snip>

> 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.

That's done through my recent work on the CMake plugin in KDevelop. We need to 
run CMake configure again to get the new code model data via the CMake file 
API.

> 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.

Feel free to fix those :) I doubt anyone has tested this properly I have to 
admit...

> > 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.

Afaik we nowadays could actually support a setup that doesn't depend on 
installation. Again, it's something we need to work on but it is definitely 
possible - esp. considering that we unified kdevelop + kdevplatform into one 
big repo. What is needed is ensuring that the binary, library and plugins all 
go to the "right" relative paths in the build dir, then everything should work 
magically I believe. Definitely something that would be appreciated if you 
could work on it!

Personally, I've always followed a workflow like Sven, i.e. I have one 
KDevelop installation I use for everything (including work-work!). It's a 
debug build. When I work on KDevelop I just open my session for the kdevelop 
project(s) and then hack away. For testing I then use a different session. 
That way I can keep the "stable" kdevelop session alive for the development 
and only test the "unstable" stuff in my test session.

Cheers
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20200329/8286c18f/attachment.sig>