On 02/13/2017 10:18 PM, Justin Berger wrote:
> Should I resumbit the MR to continue the discussion there?
Justin submitted a new MR [1]. I encourage everyone that participated
in this thread to take a look.
Thanks,
-Brad
[1] https://gitlab.kitware.com/cmake/cmake/merge_requests/483
--
Power
On Mon, Feb 13, 2017 at 20:18:02 -0700, Justin Berger wrote:
> I agree on the maximizing code reuse, but that doesn't require them to use
> the same operational mode -- the two modes do fundamentally different
> things; even while sharing most internal components. Is the idea that you
> could only
19:54, 14 February 2017 г., Ben Boeckel :On Mon, Feb 13, 2017 at 20:18:02 -0700, Justin Berger wrote: I agree on the maximizing code reuse, but that doesn't require them to use the same operational mode -- the two modes do fundamentally different things; even while sharing most internal components.
On 02/13/2017 10:18 PM, Justin Berger wrote:
> I agree on the maximizing code reuse, but that doesn't require them to use
> the same operational mode -- the two modes do fundamentally different things
Right. We shouldn't necessarily expect the server to start and then decide
whether it is a code
>
> I'd like to see if we can make the debug server part of the existing server
> mode rather than adding another mode as the original MR does. The current
> server mode already has infrastructure for protocol version negotiation,
> capability listing, etc. We should be able to use/re-use that as
On 02/02/2017 01:15 PM, Justin Berger wrote:
> 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 so
On 01/31/2017 02:55 PM, Justin Berger wrote:
> 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
Hi Justin, Adam et al,
made a proof of concept for a debugger integrated into CMake
Very nice to see someone moving this forward :+1
> Wish this existed since forever.
FWIW, you may want to also look at what was done by Matt here:
https://github.com/thewtex/cmakedbg
Hth
Jc
--
+1 919 869
> 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 spac
On Thu, Feb 2, 2017 at 12:02 PM, Milian Wolff 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-
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 sam
> 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
On 01/31/2017 02:26 AM, Tobias Hunger wrote:
> I liked the snapshots that were in Stephen Kelly's daemon-mode
> patch much better than an interactive debugger.
>
> Is somebody working on the snapshot infrastructure?
Not that I'm aware. Some of the infrastructure is already there.
See `Source/cmS
On Jan 30, 2017 20:03, "Sylvain Joubert" wrote:
> c) What is the best
> approach to make this kind of feature appealing to IDE / UI tools which
> currently work with CMake?
>
>
If I recall correctly, one of the initial use cases for the server mode was
exactly that. The very first prototype of S
Le 30/01/2017 à 17:09, Justin Berger a écrit :
a) Is this feature worthwhile for eventual merge into CMake?
No doubt! :-)
> c) What is the best
approach to make this kind of feature appealing to IDE / UI tools which
currently work with CMake?
If I recall correctly, one of the initial use c
+1
Wish this existed since forever.
Cheers,
Adam
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of
Justin Berger
Sent: Monday, January 30, 2017 11:10 AM
To: cmake-developers@cmake.org
Subject: [cmake-developers] Debugger for CMake
I've made a proof of concep
I've made a proof of concept for a debugger integrated into CMake. The code
and notes about the implementation are here:
* https://gitlab.kitware.com/cmake/cmake/merge_requests/447
It is still a work in progress and there is still a decent chunk of work to
be done. The general approach works thou
17 matches
Mail list logo
