> 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 <dan...@pfeifer-mail.de> wrote: > On Thu, Feb 2, 2017 at 12:02 PM, Milian Wolff <m...@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 >
-- 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