[cmake-developers] Debugger for CMake

[Justin Berger]

> GDB's MI is a standard protocol used by both clang and LLDB but I think it
will be overkill for something like CMake.

I did look at GDB's protocols and also came to the conclusion that the
mismatch was too great to be worth it -- they really rely on having a a
symbol table and mapped memory space to be useful for introspection.

> I mean do you really expect people to go line-by-line through a cmake
script to see how it gets evaluated? 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'd mostly expect the most used use case to be setting a breakpoint at a
particular line of code, running til that line, and inspecting given
variables around that point. Everyone I know who has used CMake has done
the equivalent of printf debugging with message to do this, and it has the
same drawbacks.

I also think it'd be incredibly useful to be able to step into and break
inside of standard modules.

> 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

I have yet to see a medium to large size project that is meant to be cross
platform that doesn't look suspiciously like a somewhat complicated domain
specific script. That isn't a dig at CMake, the problems that come from
cross platform and dependency management bolted onto compile and link
commands that are subtly different between compilers and OS's are
complicated.

And to be clear, I'm all for an approach that is modern and pleasant that
handles these complications to the point of triviality, but we aren't there
and I don't think perfect should be the enemy of good.

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

I haven't seen the proposals on how to implement alternative language front
ends from the technical side; but the debugger shouldn't have any explicit
dependence on the front-end language; its called via hooks (right now in
cmMakefile) and has some introspection capabilities via that same class.
Depending on the implementation, I could see new language front-ends not
being able to use the built-in debugger, but I don't think it'd complicate
new work in that area. If you see anything in the implementation that would
though, let me know.

Have a good one,
Justin

On Thu, Feb 2, 2017 at 6:18 AM, Daniel Pfeifer <daniel at pfeifer-mail.de>
wrote:

> 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
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170202/228f9607/attachment.html>