<div dir="ltr">> <span style="font-size:12.8px">GDB's MI is a standard protocol used by both clang and LLDB but I think it</span><br style="font-size:12.8px"><span style="font-size:12.8px">will be overkill for something like CMake.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">I mean do you really </span><span style="font-size:12.8px">expect people to go line-by-line through a cmake script to see how it gets </span><span style="font-size:12.8px">evaluated? I don't. Rather, I want to see the effect a call has on the CMake </span><span style="font-size:12.8px">state, i.e. the approach that Stephen took is far better in my eyes.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I also think it'd be incredibly useful to be able to step into and break inside of standard modules. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">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</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div>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. </div><div><span style="font-size:12.8px"><br></span></div><div>Have a good one,</div><div>Justin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 2, 2017 at 6:18 AM, Daniel Pfeifer <span dir="ltr"><<a href="mailto:daniel@pfeifer-mail.de" target="_blank">daniel@pfeifer-mail.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Thu, Feb 2, 2017 at 12:02 PM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_111638841834067054gmail-">On Dienstag, 31. Januar 2017 20:55:45 CET Justin Berger wrote:<br>
> > I liked the snapshots that were in Stephen Kelly's daemon-mode patch much<br>
><br>
> better than an interactive debugger.<br>
><br>
> I'm not sure these tools have that much use-case overlap. As far as I can<br>
> tell, snapshots has roughly the same overhead / functionality as reversible<br>
> interactive debuggers; which is non trivial. Which tool is best for a given<br>
> problem seems situational; and having both seems useful.<br>
><br>
> I looked through the code for cmServer, since it maintains an instance of<br>
> cmake in process, it could register as a debug listener and get events /<br>
> set breakpoints and all in response to different requests coming in. The<br>
> issue here though is that it seems like (and maybe this is wrong?) the<br>
> actual call out to configure blocks on the libuv loop thread so it can't<br>
> get or process any requests while configure is running; so maybe keeping<br>
> them as seperate services running on separate loops is better.<br>
><br>
> The only way I could see it making sense to use a completely different<br>
> protocol would be if there were a semi-standard debugger protocol used in<br>
> different IDE's for debugging interpreted code, and then I think it makes<br>
> sense to pursue those. However, I did some research into that and didn't<br>
> find anything especially relevant -- IDE maintainers would obviously have a<br>
> better sense of that though. Also, even if there is such a thing, there is<br>
> no reason not to support multiple debug protocols; it is just a matter of<br>
> prioritization.<br>
<br>
</span>GDB's MI is a standard protocol used by both clang and LLDB but I think it<br>
will be overkill for something like CMake. From my POV, CMake is very<br>
different from a normal application that you may debug. I mean do you really<br>
expect people to go line-by-line through a cmake script to see how it gets<br>
evaluated?</blockquote><div><br></div></div></div><div>It depends.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I don't. Rather, I want to see the effect a call has on the CMake<br>
state, i.e. the approach that Stephen took is far better in my eyes.</blockquote><div><br></div></span><div>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.</div>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".</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers, Daniel</div></div></div>
<br>--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/<wbr>CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake-developers" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/cmake-<wbr>developers</a><br></blockquote></div><br></div>