Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Debugger plugin : remote debugging : request + remarks
killerbot:
I think it would be nice, to add a check box in the remote debugging configuration area, to allow to use "extended-remote", instead of just "remote".
secondly, I noticed in my very "first" remote debugging use case with gdb, that in CB, the debugger "Command" field didn't allow anything to be typed in.
Is this a bug or done on purpose ?
Third : I noticed that the remote ip address and port are stored in the project file, since this file is normally under version control it is not a good idea to store this in here. Since I am debugging on my target on a certain ip address/port, while another colleague is doing the same on his device, at yet another ip/port. And as such our cbp file get's changed all the time, and if this change get's into the the version control system, it is no fun.
What do the other devs think about this ?
oBFusCATed:
--- Quote from: killerbot on June 19, 2012, 09:38:39 pm ---I think it would be nice, to add a check box in the remote debugging configuration area, to allow to use "extended-remote", instead of just "remote".
--- End quote ---
Patches welcome.
--- Quote from: killerbot on June 19, 2012, 09:38:39 pm ---Third : I noticed that the remote ip address and port are stored in the project file, since this file is normally under version control it is not a good idea to store this in here. Since I am debugging on my target on a certain ip address/port, while another colleague is doing the same on his device, at yet another ip/port. And as such our cbp file get's changed all the time, and if this change get's into the the version control system, it is no fun.
--- End quote ---
There is no general mechanism for storing staff in non-project files, so nothing will be done (at least by me) about this until some general API is added.
Currently I've not time to do it, but I have it in the TODO for a long time, so when I get some free time I'll see what I can do about this API.
I don't like the current situation with the .depend, .layout, .workspace.layout, .bmars and other files piling in the project directory, it is pretty ugly and I don't want to make it even worse...
killerbot:
ok I will take care of the first part,
what is the answer to the second ?
New issue (can I ask for help from our debugger expert ?) :
Edit break point dialog is rather small, but the thing to improve is, it should be able to be resized, that way one can ensure that for example a long "expression" is fully visible.
oBFusCATed:
--- Quote from: killerbot on June 20, 2012, 11:51:01 am ---what is the answer to the second ?
--- End quote ---
Probably a bug, but I don't know what was the purpose for these commands, you have to look at the code and svn blame to get the idea.
--- Quote from: killerbot on June 20, 2012, 11:51:01 am ---New issue (can I ask for help from our debugger expert ?) :
Edit break point dialog is rather small, but the thing to improve is, it should be able to be resized, that way one can ensure that for example a long "expression" is fully visible.
--- End quote ---
I think this one is simpe XRC dialog, so you can edit the file and it should be able to be resizable.
ouch:
You know I always thought Codeblocks needed a separate .settings file to store misc settings for the project. Even so much as to say that we need an option of storing things in a separate .settings file or in the project file. (Some settings you want to share with everyone, but others you just want for yourself) But oBFusCATed is right, there might be getting too many "project" files. Maybe we need to make the cbp files an archive based format similar to the open document movement. Or maybe we should switch to a simple database like sqlite3. Personally I would prefer a database based approach as that would make loading a hell of a lot faster for large projects. You could even have export/import functions so people could still work with plain text files if they wanted too.
But that's just my 2 cents... ;)
Navigation
[0] Message Index
[#] Next page
Go to full version