Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Adding a target type for embedded development?
WinterMute:
--- Quote from: scarphin on December 15, 2014, 12:30:14 am ---What I understand from your posts is you run the simulator with CB 'Run' command and launch a manual 'gdb' process to connect to it. If that is the case what I would do is:
1- Insert '$(TARGET_COMPILER_DIR)..\emulators\3dmoo $(TARGET_OUPUT_DIR)$(TARGET_OUTPUT_BASENAME).3dsx -gdbport 1000' into 'additional shell commands before connection',
2- Start debugging (CB 'Debug' command).
Which part of this doesn't work or meet your requirements? If not what is the advantage?
--- End quote ---
If I do that then gdb will never start since the emulator won't return control until it finishes. Backgrounding the process is different between windows (putting start at the beginning of the command) and OSX/Linux ( ending command with & ) which means that a project file created on one system will then not be transferable to another without editing. The simplest way to deal with that seems to be to launch the host application as part of the process that starts gdb, otherwise it involves using a script to detect host os or something like cb_console_runner that forks the host application and returns to the caller.
My ultimate goal here is to have a version of Code::Blocks that I can distribute with the devkitPro toolchains so that end users can have a project set up, ready to compile and run or debug with a couple of button clicks. The plan is to provide project files with the example code as well which means I'd really rather not have the user need to edit things before they can debug code just because the project was set up on a different OS.
--- Quote from: oBFusCATed on December 15, 2014, 01:42:07 am ---
--- Quote from: WinterMute on December 14, 2014, 11:22:20 pm ---It turned out to be useful to have extra arguments passed to applications when debugging. For instance I have a couple of projects that benefit from switching off stdio redirection when debugging to get messages in the gdb console and turn off saving to config files, things like that. Thought it might be useful for other people too.
--- End quote ---
I'm not sure this is a good idea them. This dialog is confusing without this field and now it will become even more confusing.
I'd prefer this option be part of the debugger settings in the project -> properties dialog.
--- End quote ---
OK, that seems reasonable.
I have a smaller set of changes without the debug arguments patches at https://github.com/WinterMute/codeblocks_sf/compare/hosted-application-changes
Is it possible to get access to the debugger settings from a wizard script?
oBFusCATed:
--- Quote from: WinterMute on December 15, 2014, 10:12:29 pm ---Backgrounding the process is different between windows (putting start at the beginning of the command) and OSX/Linux ( ending command with & )
--- End quote ---
I think this could be done with the macro manager.
You can provide a macro that is named something like: $START_BACKGROUND(<command>) and then this macro does the right thing on ever supported OS.
Another option is add a checkbox somewhere in the UI of the debugger, which tells it to start commands in the background.
The third option is to wrap your executable in a shell/batch script.
--- Quote from: WinterMute on December 15, 2014, 10:12:29 pm ---Is it possible to get access to the debugger settings from a wizard script?
--- End quote ---
There is a method in the project to get access to the plugin xml tags, but I don't know if it is exposed to squirrel. Probably not.
scarphin:
--- Quote from: WinterMute on December 15, 2014, 10:12:29 pm ---
--- Quote from: scarphin on December 15, 2014, 12:30:14 am ---What I understand from your posts is you run the simulator with CB 'Run' command and launch a manual 'gdb' process to connect to it. If that is the case what I would do is:
1- Insert '$(TARGET_COMPILER_DIR)..\emulators\3dmoo $(TARGET_OUPUT_DIR)$(TARGET_OUTPUT_BASENAME).3dsx -gdbport 1000' into 'additional shell commands before connection',
2- Start debugging (CB 'Debug' command).
Which part of this doesn't work or meet your requirements? If not what is the advantage?
--- End quote ---
If I do that then gdb will never start since the emulator won't return control until it finishes. Backgrounding the process is different between windows (putting start at the beginning of the command) and OSX/Linux ( ending command with & ) which means that a project file created on one system will then not be transferable to another without editing. The simplest way to deal with that seems to be to launch the host application as part of the process that starts gdb, otherwise it involves using a script to detect host os or something like cb_console_runner that forks the host application and returns to the caller.
My ultimate goal here is to have a version of Code::Blocks that I can distribute with the devkitPro toolchains so that end users can have a project set up, ready to compile and run or debug with a couple of button clicks. The plan is to provide project files with the example code as well which means I'd really rather not have the user need to edit things before they can debug code just because the project was set up on a different OS.
--- End quote ---
Ok, fair enough, now I get your point. Btw have you considered providing different project files for each supported OS? Afaik that is what CB does currently. I'm guessing you'll have to provide OS specific CB builds in the end.
Navigation
[0] Message Index
[*] Previous page
Go to full version