[cmake-developers] Debugger for CMake

[Daniel Pfeifer]

On Thu, Feb 2, 2017 at 12:02 PM, Milian Wolff <mail at milianw.de> wrote:

> On Dienstag, 31. Januar 2017 20:55:45 CET Justin Berger wrote:
> > > I liked the snapshots that were in Stephen Kelly's daemon-mode patch
> much
> >
> > better than an interactive debugger.
> >
> > I'm not sure these tools have that much use-case overlap. As far as I can
> > tell, snapshots has roughly the same overhead / functionality as
> reversible
> > interactive debuggers; which is non trivial. Which tool is best for a
> given
> > problem seems situational; and having both seems useful.
> >
> > I looked through the code for cmServer, since it maintains an instance of
> > cmake in process, it could register as a debug listener and get events /
> > set breakpoints and all in response to different requests coming in. The
> > issue here though is that it seems like (and maybe this is wrong?) the
> > actual call out to configure blocks on the libuv loop thread so it can't
> > get or process any requests while configure is running; so maybe keeping
> > them as seperate services running on separate loops is better.
> >
> > The only way I could see it making sense to use a completely different
> > protocol would be if there were a semi-standard debugger protocol used in
> > different IDE's for debugging interpreted code, and then I think it makes
> > sense to pursue those. However, I did some research into that and didn't
> > find anything especially relevant -- IDE maintainers would obviously
> have a
> > better sense of that though. Also, even if there is such a thing, there
> is
> > no reason not to support multiple debug protocols; it is just a matter of
> > prioritization.
>
> GDB's MI is a standard protocol used by both clang and LLDB but I think it
> will be overkill for something like CMake. From my POV, CMake is very
> different from a normal application that you may debug. I mean do you
> really
> expect people to go line-by-line through a cmake script to see how it gets
> evaluated?


It depends.

I don't. Rather, I want to see the effect a call has on the CMake
> state, i.e. the approach that Stephen took is far better in my eyes.


I personally could not agree more. But that answer greatly depends on the
way you use CMake. If you use it as a build system generator and write your
CMakeLists.txt files in a clean, modern way, then Steve's approach is
perfect.
However, if you (ab)use CMake as a general purpose scripting language, then
a debugger might be welcome. Have a look at ExternalProject.cmake. You find
even more complex examples in the wild if you google for "cmake package
management".

I am against a debugger in CMake. We should invest in making the clean,
modern approach more clean, more modern, and more pleasant. Using CMake as
a general purpose scripting language should be possible but painful. Like a
continuous question whether you are using the right tool for the job. But
that is just my opinion.

PS: Adding an interactive debugger to the CMake scripting language might
complicate adding new language front-ends. If we allow an alternative
language front-end, you might be able to use existing tools to debug
complicated scripts.

Cheers, Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170202/5f917593/attachment.html>