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
