CodeLite IDE

Hello, I've worked on a standalone debugger for a scripting language a while back, can be seen here. Recently I've wanted to get back to it and get it to a releasable point. In my attempts to bring it up to date with the latest wxWidgets and such, I am reminded just how much of a pain it is to maintain. Anyways, what I'm interested in doing is possibly making a standalone debugger that adheres to a similar behavior as a standard debugger, so that it can be used in a proper IDE such as CodeLite, Eclipse, etc. Is this possible? What is the spec for the type of debugger interface that exists between CodeLite and gdb for instance? Presumably if I duplicate that communication channel I could make a standalone exe debugger that can be used from within an IDE, freeing me from re-inventing a while IDE when all I ultimately want to do is the debugger part.

Failing that, is there enough access exposed to plugins that I could control the contents of the debug windows myself from a plugin? That may be the preferred method, since script debugging tends to work differently than code debugging. In the case of this scripting language, essentially the host app(the app running the scripts to be debugged), will send the entire contents of the scripts to the debugger, freeing them from having to point their debugger/IDE to an accurate copy of the scripts. If this isn't possible using a standard interface then I would prefer if I could control this stuff via plugin if possible.

Thoughts?

The

DrEvil wrote:What is the spec for the type of debugger interface that exists between CodeLite and gdb for instance?

The spec is just implementing the interface file 'debugger.h' which can be found here: http://codelite.svn.sourceforge.net/vie ... iew=markup

The plugin path is also feasible and mature.

If you need more assistant, login to the channel #codelite @ irc.freenode.net or contact me directly (eran DOT ifrah AT gmail DOT com).
Maybe after creating a debugger, we can compile a document HOWTO

You can also join the codelite-devl mailing list (and maybe we can make this mailing list active at last...) and we can discuss it over there

Eran

DrEvil, are asking how to make your debugger appear to CodeLite like gdb? If so, you will want to look at the file debuggergdb.cpp (http://codelite.svn.sourceforge.net/vie ... iew=markup). There you can see the actual commands that CodeLite sends to gdb through stdin.

I noticed in the IDE that the debugger functionality is based on selecting the executable, or attaching to a process. Typically scripting language debuggers connect via the network and exchange information that way, where the executable, working directory, or process is irrelevant. Does the plugin have control over the fields in the Quick Debug window, or what is listed on the attach debugger to process page? If no control over the widgets, perhaps there can be an ip address, port, etc added to those dialogs and if the debugger process uses those they would be active and likewise with the executable, process list, etc. Also, does the debugger support requesting source from the debugger? For example, the xdebug protocol supports requesting the full source from the application. This is typically how script debuggers get their information. It is rarely necessary to point a scripting debugger, like a lua debugger to a folder with the actual script files like we tend to have to do with c++ debugging. In that sense the debugger needs to support asking the app for the source. If all these things can be solved, I would be very interested in writing a debugger for Codelite for the GM scripting language, probably by implementing the debugger interface. I don't think I need to do something like gdb.

On a related note, I assume one could implement a 'compiler type' that would be choosable under "Compiler Type" in new project so that for example I can make a workspace of gm scripts and be able to build them all at once just like they were a bunch of arbitrary code files?

DrEvil wrote:On a related note, I assume one could implement a 'compiler type' that would be choosable under "Compiler Type" in new project so that for example I can make a workspace of gm scripts and be able to build them all at once just like they were a bunch of arbitrary code files?

Yes.

Settings -> build settings -> and hit the 'New' button. This will create a new compiler for you (clone of g++). Then simply change the toolchain under the 'Tools' tab.

Eran

Any thoughts on the bigger post? Specifically about debuggers that connect via network connections, and whether the debugger will request the source from the connected app? Is this possible now or can it be added? Needs basically additional options in the debugger dialogs that the debugger interface could use.

DrEvil wrote:Any thoughts on the bigger post? Specifically about debuggers that connect via network connections, and whether the debugger will request the source from the connected app? Is this possible now or can it be added? Needs basically additional options in the debugger dialogs that the debugger interface could use

Basically, the reason why I recommend creating a plugin instead of implementing the debugger interface, is that the debugger was created *after* I introduced the plugin design. The main difference between the two: the debugger does not has any control over the UI, while a plugin has a complete control over its widgets.

I really think that you should take the plugin path.

Eran

As a plugin, does that mean I'd have to set up my own debugger GUI panels and stuff or would I be able to still use the existing ones? The whole point of wanting to make a plugin for an existing IDE is to take advantage of existing IDE functionality, including the debug GUI. It would seem to me that you would want your standard debugger functionality to be able to support debugging over the network, so I would think it would be a reasonable request if you added ip address/port options to the debug dialogs and the debugger can implement a function that determines which fields it uses so that it can gray out the rest. Existing debuggers would just have the ip address/port greyed out, but anyone writing a scripting language debugger would use those fields.

DrEvil wrote:As a plugin, does that mean I'd have to set up my own debugger GUI panels and stuff or would I be able to still use the existing ones? The whole point of wanting to make a plugin for an existing IDE is to take advantage of existing IDE functionality, including the debug GUI. It would seem to me that you would want your standard debugger functionality to be able to support debugging over the network, so I would think it would be a reasonable request if you added ip address/port options to the debug dialogs and the debugger can implement a function that determines which fields it uses so that it can gray out the rest. Existing debuggers would just have the ip address/port greyed out, but anyone writing a scripting language debugger would use those fields.

I actually forgot about it, but since CodeLite supports gdbserver, there is an option to use IP/PORT for debugging:
right click on project settings -> debugger tab

have a look here:


Eran